Re: topro 6800 driver
Hello Anders
I found a small time for testing your code. But your code doesn't work
with my webcam. :-(
I think it doesn't have the same sensor. Can you add in the sd_init
method the check of the sensor id ? You can adjust this patch with
your sensor id :
diff -r 5a9a52f1277e linux/drivers/media/video/gspca/tp6800.c
--- a/linux/drivers/media/video/gspca/tp6800.c Sat Apr 18 18:21:49 2009 +0200
+++ b/linux/drivers/media/video/gspca/tp6800.c Mon Apr 20 17:33:15 2009 +0200
@@ -1601,8 +1601,21 @@
/* this function is called at probe and resume time */
static int sd_init(struct gspca_dev *gspca_dev)
{
+ int res = 0;
+ __u8 value;
+
/* check if the device responds */
+ REG_W(gspca_dev, TP6800_SIF_TYPE, 0x01);
+ REG_W(gspca_dev, TP6800_SIF_CONTROL, 0x01);
+ REG_W(gspca_dev, TP6800_GPIO_IO, 0x9f);
+ REG_R(gspca_dev, TP6800_GPIO_DATA, value);
+ if ((value 7) != 0x00) {
+ PDEBUG(D_ERR, init reg: 0x%02x. Unrecognized sensor., value);
+ return -1;
+ }
return 0;
+out:
+ return res;
}
/* -- start the camera -- */
Please, tell me what is your sensor id.
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: topro 6800 driver
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Anders Blomdell wrote: New version attached, handles both 640x480 and 320x240, corrected gamma table. Seems to work OK with mplayer, vlc and https://launchpad.net/python-v4l2-capture vlc v4l2://dev/video0:width=320:height=240 vlc v4l2://dev/video0:width=640:height=480 Jean-Francois: feel free to add this to gspca if it lives up to your standards, otherwise tell me what needs to be changed. Best regards /Anders Hi Anders, Before submitting a driver, please make sure it passes the checkpatch.pl script found in the linux/scripts/ folder. When I checked the tp6800.c file I got about ~4300 errors. This is due to that the file isn't using the indentation used by code in the linux tree. If you first run the Lindent script (found in the same folder) about 23 errors pop up that need to be corrected. Beware though that Lindent sometimes screw up lines so manual inspection of the code is needed. Best regards, / hälsningar, Erik -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAknWd4EACgkQN7qBt+4UG0E8LgCfQYON+qQJS7gOjnmF8BqUuuW8 M8YAoJJroBbk2CXBS+z6qCL6ZU41EOXy =RBZP -END PGP SIGNATURE- -- 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 [JPEG decoding solved]
Thomas Kaiser wrote: Thomas Kaiser wrote: Hello Anders Good news, I could decode a frame which I extracted from the usbsnoobs I did :-). See attached picture frame3-03.jpg. It uses the quality 0. Your black frame you sent me gets now correctly decode, too (frameA-01.jpg) I found the Huffman table in the Windoz driver file (TP6810.sys) at offset 0x2a59c. The QTable which I found in a text file on my Windoz box can be found in this driver file, also. I attached some binary files which I used to build the 2 attached jpeg. For example use: cat FFD8-Q0-320x240.bin huffman1.bin FFDA.bin frame3-3.bin frame3-03.jpg to make the picture frame3-03.jpg. This information should the cam get going in Linux ;-) Happy Hacking, Thomas PS: I sent this to the linux-media mail list, because somebody else is interested about this information, too. Just some comments about the observation you made on the frame header: ff d8 ff fe 28 3c 01 - Byte 6: Yes, it is the current quality setting - Byte 4 5: I think it is related to resolution. My snoops were done with 320x240 (0x141e) and Anders were made with 640x480 (0x283c), twice as big! - The rest is static OK, Things are looking brighter, I can capture single images with a slightly modified uvccapture and streaming with mplayer (with bogus colors, but identifiable image data) ucview doesn't work though; complains on huffman, but I'll look into colors first... Regards /Anders -- Anders Blomdell Email: anders.blomd...@control.lth.se Department of Automatic Control Lund University Phone:+46 46 222 4625 P.O. Box 118 Fax: +46 46 138118 SE-221 00 Lund, Sweden -- 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 [JPEG decoding solved]
Thomas Kaiser wrote: Hello Anders Good news, I could decode a frame which I extracted from the usbsnoobs I did :-). See attached picture frame3-03.jpg. It uses the quality 0. Your black frame you sent me gets now correctly decode, too (frameA-01.jpg) I found the Huffman table in the Windoz driver file (TP6810.sys) at offset 0x2a59c. The QTable which I found in a text file on my Windoz box can be found in this driver file, also. I attached some binary files which I used to build the 2 attached jpeg. For example use: cat FFD8-Q0-320x240.bin huffman1.bin FFDA.bin frame3-3.bin frame3-03.jpg to make the picture frame3-03.jpg. This information should the cam get going in Linux ;-) Happy Hacking, Thomas PS: I sent this to the linux-media mail list, because somebody else is interested about this information, too. Just some comments about the observation you made on the frame header: ff d8 ff fe 28 3c 01 - Byte 6: Yes, it is the current quality setting - Byte 4 5: I think it is related to resolution. My snoops were done with 320x240 (0x141e) and Anders were made with 640x480 (0x283c), twice as big! - The rest is static 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: Topro 6800 driver [JPEG decoding solved]
Hello Anders Good news, I could decode a frame which I extracted from the usbsnoobs I did :-). See attached picture frame3-03.jpg. It uses the quality 0. Your black frame you sent me gets now correctly decode, too (frameA-01.jpg) I found the Huffman table in the Windoz driver file (TP6810.sys) at offset 0x2a59c. The QTable which I found in a text file on my Windoz box can be found in this driver file, also. I attached some binary files which I used to build the 2 attached jpeg. For example use: cat FFD8-Q0-320x240.bin huffman1.bin FFDA.bin frame3-3.bin frame3-03.jpg to make the picture frame3-03.jpg. This information should the cam get going in Linux ;-) Happy Hacking, Thomas PS: I sent this to the linux-media mail list, because somebody else is interested about this information, too. inline: frame3-03.jpginline: frameA-01.jpg FFD8-Q0-320x240.bin Description: Binary data FFD8-Q0-640x480.bin Description: Binary data FFD8-Q1-320x280.bin Description: Binary data FFD8-Q1-640x480.bin Description: Binary data FFDA.bin Description: Binary data huffman1.bin Description: Binary data frame3-3.bin Description: Binary data
Re: Topro 6800 driver
Thomas Kaiser wrote: Hello Anders Anders Blomdell wrote: Thomas Kaiser wrote: Hello Anders Anders Blomdell wrote: Thomas Kaiser wrote: which indicates that both DQT and Huffman is present in the stream. It is _not_ present in the stream. Then I don't understand where it comes from... I do, because I implemented it into gspca V1 ;-) The cam only streams the picture data. To code the stream a _static_ JPEG header is used. The cam and the driver know this header. Therefor, the driver just builds a valid JPEG image with the known header and the stream from the cam. Anyway I did not found time to try with the JPEG header from PAC7311. And I have to apologize because I did not tell you what work I did for the PAC7311. See this: http://www.kaiser-linux.li/index.php?title=PAC7311 You should find the PAC7311 JPEG header in this source: http://www.kaiser-linux.li/files/PAC7311/gspcav1-PAC7311-20070425.tar.gz Will look into it. Check decoder/gspcadecoder.c and search for pac7311_jpeg_header. Anyway PAC7311 is working AFAIK. Which doesn't contradict that it's encoded in the stream from the camera. BTW, can you send me the header and some Bytes from your stream, the 02 8a 00 a2 80 28 a0 0a 28 thing. As ASCII in Email is OK. The entire (white?) image is in the attachment (QUALITY=0). I tried the PAC7311 header. See the result in the attached files :-( Thanks for trying though. I tested some more, and by starting at offset 7 (based on that ff00 indicates jpeg stream, and that byte 8 differs between quality 1 2, [byte 7 follows quality]) Size=152d, quality=1 ff d8 ff fe 28 3c 01 fc ff 00 45 66 9a 69 a2 95 ... Size=152a, quality=2 ff d8 ff fe 28 3c 02 f9 55 15 29 a5 52 95 34 a8 I get img0 with the DQT you found on your installation disk, while img1 is what you get with the standard DQT. Could it be that yuv=0,0,0 implies a black image? Length is still bogus though, and with yuv != 0 I still get garbage, so I assume there is some problem with the huffman coding still! I guess what I have to do, is to transform a yuv=0,0,0 image using the 17 different DQT tables you found and try to generate a huffman table that matches that data and the 17 different samples I have (of course this table will have unknowns, but it might be a starting point). /Anders -- Anders Blomdell Email: anders.blomd...@control.lth.se Department of Automatic Control Lund University Phone:+46 46 222 4625 P.O. Box 118 Fax: +46 46 138118 SE-221 00 Lund, Sweden inline: img0.jpginline: img1.jpg
Re: Topro 6800 driver
Thomas Kaiser wrote: Hello Anders Anders Blomdell wrote: When I set the RGB/YUV gains to zero, I get: 5a ff d8 ff fe 14 1e 00 fd f5 45 7e e8 f8 b8 df 49 57 ff d8 ff fe 28 3c 01 fc ff 00 45 66 9a 69 a2 95 4d 2a 12 d1 00 a2 b4 followed by a big number of repeated (0x152c bytes total): 02 8a 00 a2 80 28 a0 0a 28 and ending with: 02 8a 00 a2 80 ff d9 In binary the repeating sequence can be diveded in half: 0010 1000 1010 1010 0010 1000 0010 1000 1010 1010 0010 1000 That is more less the same sequence I get when I do my saturation stuff (white picture) :-) . As of coincidence, the same Bit pattern is found in the PAC7311 when I do the saturation stuff. And I know the PAC7311 stream. That's the reason why I wrote I am 100% sure that this is JPEG ;-) PAC7311 has a special marker between each MCU which has to be removed. I don't see such thing in this stream. So it must be pure JPEG. Which approximately adds up to 1200 repetitions of this bitpattern 2*(0x152c - 23)/9. And a 640*480 image divided in 8*8 subframes gives (640*480/(8*8)) 1200 subframes, so now the question is how much info about the Huffman table this gives us? I think nothing :-( , but you found the MCUs :-) As it looks quite the same as on the PAC7311, why not just try the Huffman table from the PAC7311? Which seems to be encoded in the stream and not defined in the sourcecode (but I'm tired, so I might well be wrong). Do you think you could extract it somehow? The frame header on the PAC7311 is ff ff 00 ff 96 62 + 1 Byte MCU Marker 44, then the JPEG data starts. Look at this: ff ff 00 ff 96 62 44 f7 ca 28 01 10 a2 80 11 0a 28 01 10 a2 80 11 0a 28 Side note: the first 01 10 is the MCU marker 44 embedded in the Bit stream. TP8610, first few Bytes with frame header: 5a ff d8 ff fe 14 1e 00 fd f5 45 7e e8 f8 b8 df 49 57 ab 0a 28 73 0a 28 02 8a 00 a2 80 28 a0 0a Therefor I think this is the start of the stream: ab 0a 28 73 0a 28 02 8a 00 a2 80 28 a0 0a Don't know why we have 73 in between :-( Hope this one helps /Anders -- Anders Blomdell Email: anders.blomd...@control.lth.se Department of Automatic Control Lund University Phone:+46 46 222 4625 P.O. Box 118 Fax: +46 46 138118 SE-221 00 Lund, Sweden -- 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: Thomas Kaiser wrote: And a 640*480 image divided in 8*8 subframes gives (640*480/(8*8)) 1200 subframes, so now the question is how much info about the Huffman table this gives us? I think nothing :-( , but you found the MCUs :-) As it looks quite the same as on the PAC7311, why not just try the Huffman table from the PAC7311? Which seems to be encoded in the stream and not defined in the sourcecode (but I'm tired, so I might well be wrong). Do you think you could extract it somehow? I think it should be in the gspca source or in the v4l_library? I didn't follow gspca code and v4l_library code lately. Anyway PAC7311 is working AFAIK. I'll check and try. 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: Topro 6800 driver
Hi Anders and others, I have already tried to create a module for my webcam (Topro TP6800). It have the same usb id (06a2:0003). But I have the same problem as you about the image data. I don't know what is the comment tag (FF:FE). I tried to skip the tag or to skip the comment with the length after this tag but the image is never good. I don't know where start the image. If you want an example of the bad result you can download this image : http://lafeuil.free.fr/webcam/images/1.jpg So, I am also in the dark. If you want to take a look to my code, you can download this file : http://lafeuil.free.fr/webcam/tp6800.c If somebody have an idea how can I transform the data, Tell me ! Good luck Thomas Champagne 2009/2/28 Anders Blomdell anders.blomd...@control.lth.se: 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
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: 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
