USB transfer logs: http://fish.homeunix.org/qcm-logs http://mag.cx/messenger/logs/ To: qce-ga-devel/at/lists.sourceforge.net From: "Jaka Mocnik" jaka/at/gnu.org Subject: [Qce-ga-devel] quickcam messenger SnoopyPro logs Date: Wed, 09 Apr 2003 18:21:42 +0200 hi! I am attempting to reverse engineer the goddamn' logitech quickcam messenger protocol. I am now analyzing the logs reported by snoopypro on windows. since they might also be of help to someone who is better at all this USB magic than me and since they might bear some similarity with the devices currently supported by this driver, I am making them available at http://fish.homeunix.org/qcm-logs logs with number 1 in them were produced after merely connecting the device to the windows box and the logs with number 2 were produced after some streaming. they are available both in .usblog format that snoopy pro can read and let you browse in a very user-friendly fashion and as XML files. feel free to have a look at them. regards, jaKa To: qce-ga-devel/at/lists.sourceforge.net From: "Christian Magnusson" mag/at/mag.cx Subject: [Qce-ga-devel] Quickcam Messenger Date: Tue, 27 May 2003 12:28:15 +0200 I got a Quickcam Messenger some days ago, and I'm trying to add the support to the current qc-usb driver. I have no clue which sensor it is, but it's very similar to VV6410. I have sniffed the usb-packet and ended up to where I am right now... The image data packets seem to differ pretty much but I'm doing my best to decode the image correctly. The driver allows me to stream the decoded image-data to xawtv but it's certainly some more work to do... :-) The device id is 0x046D / 0x08F0 and all i2c registers are mapped at address 0xE000. The qc_get_i2c() where you write to 0x1400 and read from 0x1410 doesn't work. Frame-start and frame-end packets are the same as other sensors... (0x8001/0x8002) The image data is NOT sent as 0x0200yyyy packets... (where yyyy are the length). They look like 0x02??yyyy instead (where ?? seem to be pretty random...) For example: many 021F could occour in the same frame-packet and they are not ordered in any way... Every frame is about 15600 bytes (probably in 320x240 resolution) The first bytes seem to be 0x0200-0x024F mostly, but I've seen 0x0273, 0x027B 0x027F, 0x029C and up to 0x02FD. If anyone have any ideas on the dataformat it would be nice to get some input. /Christian hex-numbers in the end are data[0], data[1] -> data[11] <7>quickcam [24.165623]: chunk id 8001 len= 0 80 1 0 0 2 F 0 7F F9 97 BD EF <7>quickcam [24.165645]: qc_frame_begin(quickcam=d5ffa000) <7>quickcam [24.165649]: chunk id 020F len= 127 2 F 0 7F F9 97 BD EF A B0 AB 0 <7>quickcam [24.165659]: chunk id 021F len= 254 2 1F 0 FE B5 A B0 AB 0 10 AB 0 <7>quickcam [24.165668]: payload=393 totaldata=381 <7>quickcam [24.175624]: chunk id 021F len= 253 2 1F 0 FD B5 2 10 AB 2 10 CB E <7>quickcam [24.175642]: chunk id 021F len= 253 2 1F 0 FD B5 0 90 A3 2 10 8B A <7>quickcam [24.175651]: chunk id 021B len= 216 2 1B 0 D8 B5 0 10 AB 0 10 AB A <7>quickcam [24.175659]: chunk id 0204 len= 35 2 4 0 23 30 21 8 B0 1 A B0 1 ...... <7>quickcam [24.445622]: chunk id 021A len= 208 2 1A 0 D0 50 81 A B0 1 A B0 23 <7>quickcam [24.445631]: chunk id 0205 len= 43 2 5 0 2B 10 AB 2 10 8B 0 10 AB <7>quickcam [24.445640]: chunk id 0215 len= 169 2 15 0 A9 50 1 A B0 1 A B0 2B <7>quickcam [24.445648]: chunk id 0208 len= 64 2 8 0 40 10 8B 0 10 AB 2 90 83 <7>quickcam [24.445656]: chunk id 0202 len= 18 2 2 0 12 83 0 10 AB 0 10 AB 0 <7>quickcam [24.445664]: chunk id 020F len= 126 2 F 0 7E 50 8B A 90 3 A B0 9 <7>quickcam [24.445673]: chunk id 8002 len= 0 80 2 0 0 B0 9 A 30 29 8 30 AB <7>quickcam [24.445685]: qc_frame_end(quickcam=d5ffa000,n=1), got 15601 bytes ..... <7>quickcam [25.048504]: qc_frame_end(quickcam=d5ffa000,n=0), got 15594 bytes <7>quickcam [25.118700]: qc_frame_end(quickcam=d5ffa000,n=0), got 15597 bytes <7>quickcam [25.468680]: qc_frame_end(quickcam=d5ffa000,n=0), got 15598 bytes <7>quickcam [25.888613]: qc_frame_end(quickcam=d5ffa000,n=0), got 15593 bytes <7>quickcam [25.958533]: qc_frame_end(quickcam=d5ffa000,n=0), got 15600 bytes To: qce-ga-devel/at/lists.sourceforge.net From: "Christian Magnusson" Subject: [Qce-ga-devel] Re: Quickcam Messenger Date: Fri, 30 May 2003 16:35:17 +0200 Hi again... I made some logs and saved them at http://mag.cx/messenger/logs/ . I hope the files could be any help for you to decode. You could read some of the notes I made on that page... The first two bytes are always "F9 97". data[1] seems to be in close connection to the total framelength. /Christian From: mag (mag/at/home.mag.cx) Subject: Re: [Qce-ga-devel] Re: Quickcam Messenger To: tuukkat/at/ee.oulu.fi (Tuukka Toivonen) Date: Mon, 2 Jun 2003 14:37:42 +0200 (MEST) > > On Fri, 30 May 2003, Christian Magnusson wrote: > > >I made some logs and saved them at http://mag.cx/messenger/logs/ . > > Got them. > > >I hope the files could be any help for you to decode. You could read some > >of the > >notes I made on that page... The first two bytes are always "F9 97". > > Yes indeed. For a long frame it's possible that the kernel log ring wraps > over before all data is saved... it would be better if you could stream the > raw data directly to the device file for program which is reading from > /dev/video... e.g. show.c in qc-usb. You could use VIDEO_PALETTE_MJPEG > which basically gives use space program directly the data coming from > camera (but you would need to do some modifications, especially modify > show.c to save data into file instead of trying to uncompress it.. unless > the uncompression works out of the box). > > Anyway, now I can test if mjpeg_decode() can decode at least the first > bytes of frames. > I have saved some frames with qc-usb/show now... You can find the files rawdata.000 - rawdata.008 at http://mag.cx/messenger/logs/ . Perhaps it's easier for you to work with those files instead. The camera is probably just pointed somewhere in my office, so they are not totally black or white frames. I have read about the STV0680 and my guess is that's Quickcam messenger use a newer variant of this IC. It has 640x480 + microphone + support for external buttons + built-in usb interface. STV0680 have constant frame-length though, but Quickcam Messenger have perhaps some added feature like some simple compression. /Christian From: Franco Favento de i Favento de Trieste f.favento at ieee dot org To: qce-ga-discussion at lists.sourceforge.net Subject: [Qce-ga-discussion] Re: QuickCam Messenger Date: Fri, 01 Aug 2003 14:59:35 +0200 Hello to all. Recently I have had a "Logitech QuickCam Messenger USB" that soon I realized isn't working (yet) with Linux. Snooping a bit inside (yes, I've open it) did show me very few codes or data, so I'm unable to do a real work on it. I was able only to do a silly hack on the qce-ga-0.40d driver to make it knowing the device and registering itself as the right driver for the device (under the hotplugging method), but I simply can't do anything useful with this. I did write for help to Logitech, but they did reply to me saying that they are not supporting Linux because it's a mess. At my subsequent message explaining the difference between kernel, device drivers and distribution they did reply with a totally useless customer satisfaction poll from the "Customer Support Logitech". In some recent messages I did read that it exists a mailing list named qce-ga-devel: can I do subscribe it? If yes, how can I do it? (Simply following the link https://lists.sourceforge.net/lists/listinfo/qce-ga-discussion did give me an error like "TCP Error: no route to host".) I can't do any real *hard* work on this subject, because I have really few spare time, but if I may eventually do some contribution I'll do happily. I send to you what I "discovered", hoping it's not annoying anyone: ------------------------------------------------------------------- Data (that is write) on the cable: ------------------------------------------------------------------- Rating: 5V=, 100mA M/N: V-UM14 P/N: 861092-0020 S/N: LZA30217249 ------------------------------------------------------------------- Writings inside, on the board: ------------------------------------------------------------------- Logitech 08292002 201619-0000 221619-0000 Rev A ------------------------------------------------------------------- Data obtained with `cat /proc/bus/usb/devices` ------------------------------------------------------------------- T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 D: Ver= 2.00 Cls=ff(vend.) Sub=ff Prot=ff MxPS= 8 #Cfgs= 1 P: Vendor=046d ProdID=08f0 Rev= 1.00 S: Product=Camera C:* #Ifs= 3 Cfg#= 1 Atr=a0 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) E: Ad=81(I) Atr=01(Isoc) MxPS= 0 Ivl= 1ms E: Ad=82(I) Atr=03(Int.) MxPS= 1 Ivl= 16ms I: If#= 0 Alt= 1 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) E: Ad=81(I) Atr=01(Isoc) MxPS=1023 Ivl= 1ms E: Ad=82(I) Atr=03(Int.) MxPS= 1 Ivl= 16ms I: If#= 1 Alt= 0 #EPs= 0 Cls=01(audio) Sub=01 Prot=00 Driver=(none) I: If#= 2 Alt= 0 #EPs= 1 Cls=01(audio) Sub=02 Prot=00 Driver=(none) E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl= 1ms I: If#= 2 Alt= 1 #EPs= 1 Cls=01(audio) Sub=02 Prot=00 Driver=(none) E: Ad=83(I) Atr=01(Isoc) MxPS= 52 Ivl= 1ms ------------------------------------------------------------------- Some my deductions: ------------------------------------------------------------------- Vendor=046d (It seems to means: "Logitech") ProdID=08f0 (It seems to means: "Quickcam Messenger USB 640x480") Rev= 1.00 ------------------------------------------------------------------- Ciau Franco