Re: Make failed - standard ubuntu 9.10
Its looking for .config file inside the kernel source. /lib/modules/2.6.31-17-generic/build/.config 1) check that /build is a symlink to /usr/src/kernel-path-source 2) IF there is something like /proc/config , copy it to /usr/src/kernel-path-source/.config IF NOT, then you could try doing a make oldconfig I really dont know that the ubuntu packages includes inside, so, those are my 2 cents... 2010/1/29 David Henig dhhe...@googlemail.com: Thanks, I've been trying to follow the wiki, but getting this error. The main kernel packages seem to all be installed, but perhaps something less obvious is missing - hard to tell without a definitive list of dependencies. Help would be much appreciated! David Németh Márton wrote: David Henig wrote: Please can someone assist, not sure what the cause of the below is? This is my second attempt to get linux tv to work, I suspect it's a basic level error - sorry I'm fairly new to Linux... output below, I'm running a fairly standard ubuntu 9.10 setup. make[1]: Entering directory `/home/david/v4l-dvb/v4l' Updating/Creating .config Preparing to compile for kernel version 2.6.31 File not found: /lib/modules/2.6.31-17-generic/build/.config at ./scripts/make_kconfig.pl line 32, IN line 4. make[1]: *** No rule to make target `.myconfig', needed by `config-compat.h'. Stop. make[1]: Leaving directory `/home/david/v4l-dvb/v4l' make: *** [all] Error 2 I think you don't have the kernel development files installed. The recommended reading would be: http://linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers 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 -- 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: Setting up the exposure time of a webcam
HI Nicolau remember to send a SOB if the patch is working, and any change let me know so i can test with others t613 users. Best Regards On Tue, Jan 26, 2010 at 3:37 PM, Jean-Francois Moine moin...@free.fr wrote: On Tue, 26 Jan 2010 15:00:53 -0200 Nicolau Werneck nwern...@gmail.com wrote: Hello. I have this very cheap webcam that I sent a patch to support on gspca the other day. The specific driver is the t613. I changed the lens of this camera, and now my images are all too bright, what I believe is due to the much larger aperture of this new lens. So I would like to try setting up a smaller exposure time on the camera (I would like to do that for other reasons too). The problem is there's no exposure option to be set when I call programs such as v4lctl. Does that mean there is definitely no way for me to control the exposure time? The hardware itself was not designed to allow me do that? Or is there still a chance I can create some C program that might do it, for example? [snip] Hello Nicolau, There are brightness, contrast, colors, autogain and some other video controls for the t613 webcams. You must use a v4l2 compliant program to change them, as vlc or v4l2ucp (but not cheese). Regards. -- 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 -- 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: gspca_sunplus problem: more than one device is created
Did that happen with the included version on the kernel?. The kernel is calling the probe for the isoch and the bulk, i really dont have a sunplus webcam to test, and ignore the older behavior, that's why i am asking. Best Regards 2010/1/10 Németh Márton nm...@freemail.hu: Hi, I tried the gspca_sunplus driver from http://linuxtv.org/hg/~jfrancois/gspca/ rev 13915 on top of Linux kernel 2.6.32. When I plug the Trust 610 LCD pow...@m Zoom device in webcam mode (0x06d6:0x0031) then two devices are created: /dev/video0 and /dev/video1: [31636.528184] usb 3-2: new full speed USB device using uhci_hcd and address 5 [31636.740722] usb 3-2: New USB device found, idVendor=06d6, idProduct=0031 [31636.740744] usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [31636.740760] usb 3-2: Product: Trust 610 LCD pow...@m ZOOM [31636.740772] usb 3-2: Manufacturer: Trust [31636.744229] usb 3-2: configuration #1 chosen from 1 choice [31636.747584] gspca: probing 06d6:0031 [31636.760176] gspca: video0 created [31636.760643] gspca: probing 06d6:0031 [31636.772063] gspca: video1 created The /dev/video0 is working correctly but the /dev/video1 just causes error: $ ./svv -d /dev/video1 raw pixfmt: JPEG 464x480 pixfmt: RGB3 464x480 mmap method VIDIOC_STREAMON error 5, Input/output error Here is the USB descriptor of the device: Trust 610 LCD pow...@m ZOOM Manufacturer: Trust Speed: 12Mb/s (full) USB Version: 1.00 Device Class: 00(ifc ) Device Subclass: 00 Device Protocol: 00 Maximum Default Endpoint Size: 8 Number of Configurations: 1 Vendor Id: 06d6 Product Id: 0031 Revision Number: 1.00 Config Number: 1 Number of Interfaces: 2 Attributes: 80 MaxPower Needed: 500mA Interface Number: 0 Name: sunplus Alternate Number: 0 Class: ff(vend.) Sub Class: 00 Protocol: 00 Number of Endpoints: 1 Endpoint Address: 81 Direction: in Attribute: 1 Type: Isoc Max Packet Size: 0 Interval: 1ms Interface Number: 0 Name: sunplus Alternate Number: 1 Class: ff(vend.) Sub Class: 00 Protocol: 00 Number of Endpoints: 1 Endpoint Address: 81 Direction: in Attribute: 1 Type: Isoc Max Packet Size: 128 Interval: 1ms Interface Number: 0 Name: sunplus Alternate Number: 2 Class: ff(vend.) Sub Class: 00 Protocol: 00 Number of Endpoints: 1 Endpoint Address: 81 Direction: in Attribute: 1 Type: Isoc Max Packet Size: 384 Interval: 1ms Interface Number: 0 Name: sunplus Alternate Number: 3 Class: ff(vend.) Sub Class: 00 Protocol: 00 Number of Endpoints: 1 Endpoint Address: 81 Direction: in Attribute: 1 Type: Isoc Max Packet Size: 512 Interval: 1ms Interface Number: 0 Name: sunplus Alternate Number: 4 Class: ff(vend.) Sub Class: 00 Protocol: 00 Number of Endpoints: 1 Endpoint Address: 81 Direction: in Attribute: 1 Type: Isoc Max Packet Size: 640 Interval: 1ms Interface Number: 0 Name: sunplus Alternate Number: 5 Class: ff(vend.) Sub Class: 00 Protocol: 00 Number of Endpoints: 1 Endpoint Address: 81 Direction: in Attribute: 1 Type: Isoc Max Packet Size: 768 Interval: 1ms Interface Number: 0 Name: sunplus Alternate Number: 6 Class: ff(vend.) Sub Class: 00 Protocol: 00 Number of Endpoints: 1 Endpoint Address: 81 Direction: in Attribute: 1 Type: Isoc Max Packet Size: 896
Re: problem webcam gspca 2.6.32
Also, if you can, try the lastest from linuxtv.org On Sat, Jan 9, 2010 at 10:05 AM, Sean kn...@toaster.net wrote: What kind of errors or problems are you getting? Can you turn on debugging and give us some output? Sean --Original Message-- From: sacarde Sender: linux-media-ow...@vger.kernel.org To: linux-media@vger.kernel.org Subject: problem webcam gspca 2.6.32 Sent: Jan 9, 2010 12:32 AM hi, on my archlinux-64 I have a webcam: 0471:0322 Philips DMVC1300K PC Camera until one mounth ago this works OK with driver: gspca_sunplus now with kernel 2.6.32 not works I start cheese and I view: http://sacarde.interfree.it/errore-cheese.png and this messages: Cheese 2.28.1 Probing devices with HAL... Found device 0471:0322, getting capabilities... Detected v4l2 device: USB Camera (0471:0322) Driver: sunplus, version: 132864 Capabilities: 0x0501 Probing supported video formats... from dmesg: ... gspca: probing 0471:0322 gspca: probe ok ... /dev/video0 is created I try to downgrade previus kernel kernel26 2.6.31.6-1 and dependencies and it works: when it works 2.6.31: Driver: sunplus, version: 132608 thankyou saca...@tiscali.it -- 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 -- 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 to support for 0x0802 sensor in t613.c
Hi Nicoulau,
could you try the attached patch and add the Signed-Off by so we can
merge it???
It's your patch, just removed some lines.
Best Regards
On Fri, Dec 18, 2009 at 4:52 PM, leandro Costantino
lcostant...@gmail.com wrote:
Nicolau, if you need help, let me know.
I also, sent you some mails asking for the patch for review some weeks
ago, i thougth you were missing :)
good woork
best regards
On Fri, Dec 18, 2009 at 8:13 PM, Jean-Francois Moine moin...@free.fr wrote:
On Fri, 18 Dec 2009 16:46:04 -0200
Nicolau Werneck nwern...@gmail.com wrote:
Hello. I am a clueless n00b, and I can't make patches or use any
proper development tools. But I made this modification to t613.c to
support this new sensor. It is working fine with me. I just cleaned
the code up a bit and compiled and tested with the 2.6.32 kernel, and
it seems to be working fine.
If somebody could help me creating a proper patch to submit to the
source tree, I would be most grateful. The code is attached.
Hello Nicolau,
Your code seems fine. To create a patch, just go to the linux tree
root, make a 'diff -u' from the original file to your new t613.c, edit
it, at the head, add a comment and a 'Signed-off-by: your email', and
submit to the mailing-list with subject '[PATCH] gspca - t613: Add new
sensor lt168g'.
BTW, as you know the name of your sensor, do you know the real name of
the sensor '0x803' ('other')? (it should be in some xxx.ini file in a
ms-win driver, but I could not find it - the table n4_other of t613.c
should be a table 'Regxxx' in the xx.ini)
Best regards.
--
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
diff -Nru gspca-54a57b75f98c/linux/drivers/media/video/gspca/t613.c gspca-54a57b75f98c-dev/linux/drivers/media/video/gspca/t613.c
--- gspca-54a57b75f98c/linux/drivers/media/video/gspca/t613.c 2009-12-30 02:53:07.0 -0500
+++ gspca-54a57b75f98c-dev/linux/drivers/media/video/gspca/t613.c 2009-12-30 10:52:47.0 -0500
@@ -52,6 +52,7 @@
#define SENSOR_OM6802 0
#define SENSOR_OTHER 1
#define SENSOR_TAS5130A 2
+#define SENSOR_LT168G 3 /* must verify if this is the actual model */
};
/* V4L2 controls supported by the driver */
@@ -306,6 +307,17 @@
0xbe, 0x36, 0xbf, 0xff, 0xc2, 0x88, 0xc5, 0xc8,
0xc6, 0xda
};
+static const u8 n4_lt168g[] = {
+ 0x66, 0x01, 0x7f, 0x00, 0x80, 0x7c, 0x81, 0x28,
+ 0x83, 0x44, 0x84, 0x20, 0x86, 0x20, 0x8a, 0x70,
+ 0x8b, 0x58, 0x8c, 0x88, 0x8d, 0xa0, 0x8e, 0xb3,
+ 0x8f, 0x24, 0xa1, 0xb0, 0xa2, 0x38, 0xa5, 0x20,
+ 0xa6, 0x4a, 0xa8, 0xe8, 0xaf, 0x38, 0xb0, 0x68,
+ 0xb1, 0x44, 0xb2, 0x88, 0xbb, 0x86, 0xbd, 0x40,
+ 0xbe, 0x26, 0xc1, 0x05, 0xc2, 0x88, 0xc5, 0xc0,
+ 0xda, 0x8e, 0xdb, 0xca, 0xdc, 0xa8, 0xdd, 0x8c,
+ 0xde, 0x44, 0xdf, 0x0c, 0xe9, 0x80
+};
static const struct additional_sensor_data sensor_data[] = {
{/* 0: OM6802 */
@@ -422,6 +434,23 @@
.stream =
{0x0b, 0x04, 0x0a, 0x40},
},
+{/* 3: LT168G */
+ .n3 = {0x61, 0xc2, 0x65, 0x68, 0x60, 0x00},
+ .n4 = n4_lt168g,
+ .n4sz = sizeof n4_lt168g,
+ .reg80 = 0x7c,
+ .reg8e = 0xb3,
+ .nset8 = {0xa8, 0xf0, 0xc6, 0xba, 0xc0, 0x00},
+ .data1 = {0xc0, 0x38, 0x08, 0x10, 0xc0, 0x30, 0x10, 0x40,
+ 0xb0, 0xf4},
+ .data2 = {0x40, 0x80, 0xc0, 0x50, 0xa0, 0xf0, 0x53, 0xa6,
+ 0xff},
+ .data3 = {0x40, 0x80, 0xc0, 0x50, 0xa0, 0xf0, 0x53, 0xa6,
+ 0xff},
+ .data4 = {0x66, 0x41, 0xa8, 0xf0},
+ .data5 = {0x0c, 0x03, 0xab, 0x4b, 0x81, 0x2b},
+ .stream = {0x0b, 0x04, 0x0a, 0x28},
+},
};
#define MAX_EFFECTS 7
@@ -758,6 +787,10 @@
PDEBUG(D_PROBE, sensor tas5130a);
sd-sensor = SENSOR_TAS5130A;
break;
+ case 0x0802:
+ PDEBUG(D_PROBE, sensor lt168g);
+ sd-sensor = SENSOR_LT168G;
+ break;
case 0x0803:
PDEBUG(D_PROBE, sensor 'other');
sd-sensor = SENSOR_OTHER;
@@ -800,6 +833,13 @@
reg_w_buf(gspca_dev, sensor-n3, sizeof sensor-n3);
reg_w_buf(gspca_dev, sensor-n4, sensor-n4sz);
+ if (sd-sensor == SENSOR_LT168G) {
+ test_byte = reg_r(gspca_dev, 0x80);
+ PDEBUG(D_STREAM, Reg 0x%02x = 0x%02x, 0x80,
+ test_byte);
+ reg_w(gspca_dev, 0x6c80);
+ }
+
reg_w_ixbuf(gspca_dev, 0xd0, sensor-data1, sizeof sensor-data1);
reg_w_ixbuf(gspca_dev, 0xc7, sensor-data2, sizeof sensor-data2);
reg_w_ixbuf(gspca_dev, 0xe0, sensor-data3, sizeof sensor-data3);
@@ -824,6 +864,13 @@
reg_w_buf(gspca_dev, sensor-nset8, sizeof sensor-nset8);
reg_w_buf(gspca_dev, sensor-stream, sizeof sensor-stream);
+ if (sd-sensor == SENSOR_LT168G) {
+ test_byte = reg_r(gspca_dev, 0x80);
+ PDEBUG(D_STREAM, Reg 0x%02x = 0x%02x, 0x80,
+ test_byte);
+ reg_w(gspca_dev, 0x6c80);
+ }
+
reg_w_ixbuf(gspca_dev, 0xd0, sensor-data1, sizeof sensor-data1);
reg_w_ixbuf(gspca_dev, 0xc7, sensor-data2, sizeof sensor-data2
Re: patch to support for 0x0802 sensor in t613.c
Nicolau, if you need help, let me know.
I also, sent you some mails asking for the patch for review some weeks
ago, i thougth you were missing :)
good woork
best regards
On Fri, Dec 18, 2009 at 8:13 PM, Jean-Francois Moine moin...@free.fr wrote:
On Fri, 18 Dec 2009 16:46:04 -0200
Nicolau Werneck nwern...@gmail.com wrote:
Hello. I am a clueless n00b, and I can't make patches or use any
proper development tools. But I made this modification to t613.c to
support this new sensor. It is working fine with me. I just cleaned
the code up a bit and compiled and tested with the 2.6.32 kernel, and
it seems to be working fine.
If somebody could help me creating a proper patch to submit to the
source tree, I would be most grateful. The code is attached.
Hello Nicolau,
Your code seems fine. To create a patch, just go to the linux tree
root, make a 'diff -u' from the original file to your new t613.c, edit
it, at the head, add a comment and a 'Signed-off-by: your email', and
submit to the mailing-list with subject '[PATCH] gspca - t613: Add new
sensor lt168g'.
BTW, as you know the name of your sensor, do you know the real name of
the sensor '0x803' ('other')? (it should be in some xxx.ini file in a
ms-win driver, but I could not find it - the table n4_other of t613.c
should be a table 'Regxxx' in the xx.ini)
Best regards.
--
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
--
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: uvcvideo kernel panic when using libv4l
That sould be the correct.
Pablo, note that using svv.c with read method as implemented there,
should work ok.
http://moinejf.free.fr/svv.c
On Wed, Dec 16, 2009 at 7:51 AM, Pablo Baena pba...@gmail.com wrote:
With that patch, libv4l throws an error at some point, no crashes so far
though:
libv4l2: error dequeuing buf: Invalid argument
read error 22, Invalid argument
On Tue, Dec 15, 2009 at 9:12 PM, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
Hi Leandro and Pablo,
could you please try the following patch ? It closes a race window that I
believe could be at the core of your kernel panic.
diff -r c1f376eae978 linux/drivers/media/video/uvc/uvc_queue.c
--- a/linux/drivers/media/video/uvc/uvc_queue.c Sat Dec 12 18:57:17 2009
+0100
+++ b/linux/drivers/media/video/uvc/uvc_queue.c Wed Dec 16 01:10:21 2009
+0100
@@ -59,7 +59,7 @@
* returns immediately.
*
* When the buffer is full, the completion handler removes it from the irq
- * queue, marks it as ready (UVC_BUF_STATE_DONE) and wakes its wait
queue.
+ * queue, marks it as ready (UVC_BUF_STATE_READY) and wakes its wait
queue.
* At that point, any process waiting on the buffer will be woken up. If a
* process tries to dequeue a buffer after it has been marked ready, the
* dequeing will succeed immediately.
@@ -196,11 +196,12 @@
switch (buf-state) {
case UVC_BUF_STATE_ERROR:
- case UVC_BUF_STATE_DONE:
+ case UVC_BUF_STATE_READY:
v4l2_buf-flags |= V4L2_BUF_FLAG_DONE;
break;
case UVC_BUF_STATE_QUEUED:
case UVC_BUF_STATE_ACTIVE:
+ case UVC_BUF_STATE_DONE:
v4l2_buf-flags |= V4L2_BUF_FLAG_QUEUED;
break;
case UVC_BUF_STATE_IDLE:
@@ -341,13 +342,14 @@
uvc_trace(UVC_TRACE_CAPTURE, [W] Corrupted data
(transmission error).\n);
ret = -EIO;
- case UVC_BUF_STATE_DONE:
+ case UVC_BUF_STATE_READY:
buf-state = UVC_BUF_STATE_IDLE;
break;
case UVC_BUF_STATE_IDLE:
case UVC_BUF_STATE_QUEUED:
case UVC_BUF_STATE_ACTIVE:
+ case UVC_BUF_STATE_DONE:
default:
uvc_trace(UVC_TRACE_CAPTURE, [E] Invalid buffer state %u
(driver bug?).\n, buf-state);
@@ -383,7 +385,7 @@
buf = list_first_entry(queue-mainqueue, struct uvc_buffer, stream);
poll_wait(file, buf-wait, wait);
- if (buf-state == UVC_BUF_STATE_DONE ||
+ if (buf-state == UVC_BUF_STATE_READY ||
buf-state == UVC_BUF_STATE_ERROR)
mask |= POLLIN | POLLRDNORM;
@@ -489,6 +491,7 @@
spin_lock_irqsave(queue-irqlock, flags);
list_del(buf-queue);
+ buf-state = UVC_BUF_STATE_READY;
if (!list_empty(queue-irqqueue))
nextbuf = list_first_entry(queue-irqqueue, struct
uvc_buffer,
queue);
diff -r c1f376eae978 linux/drivers/media/video/uvc/uvc_video.c
--- a/linux/drivers/media/video/uvc/uvc_video.c Sat Dec 12 18:57:17 2009
+0100
+++ b/linux/drivers/media/video/uvc/uvc_video.c Wed Dec 16 01:10:21 2009
+0100
@@ -578,8 +578,7 @@
uvc_video_decode_end(stream, buf, mem,
urb-iso_frame_desc[i].actual_length);
- if (buf-state == UVC_BUF_STATE_DONE ||
- buf-state == UVC_BUF_STATE_ERROR)
+ if (buf-state == UVC_BUF_STATE_DONE)
buf = uvc_queue_next_buffer(stream-queue, buf);
}
}
@@ -637,8 +636,7 @@
if (!stream-bulk.skip_payload buf != NULL) {
uvc_video_decode_end(stream, buf, stream-bulk.header,
stream-bulk.payload_size);
- if (buf-state == UVC_BUF_STATE_DONE ||
- buf-state == UVC_BUF_STATE_ERROR)
+ if (buf-state == UVC_BUF_STATE_DONE)
buf = uvc_queue_next_buffer(stream-queue,
buf);
}
diff -r c1f376eae978 linux/drivers/media/video/uvc/uvcvideo.h
--- a/linux/drivers/media/video/uvc/uvcvideo.h Sat Dec 12 18:57:17 2009
+0100
+++ b/linux/drivers/media/video/uvc/uvcvideo.h Wed Dec 16 01:10:21 2009
+0100
@@ -370,7 +370,8 @@
UVC_BUF_STATE_QUEUED = 1,
UVC_BUF_STATE_ACTIVE = 2,
UVC_BUF_STATE_DONE = 3,
- UVC_BUF_STATE_ERROR = 4,
+ UVC_BUF_STATE_READY = 4,
+ UVC_BUF_STATE_ERROR = 5,
};
struct uvc_buffer {
--
Regards,
Laurent Pinchart
--
Not possessing the gift of reflection, a dog does not know that he
does not know, and does not understand that he understands nothing;
we, on the other hand, are aware of both. If we behave otherwise, it
is from stupidity, or else from
Re: PATCH- gspca: added chipset revision sensor
Jean,
let me know , if you need to the test this patch, since i added the
tas1530k long time ago, and still have the webcam :)
Best Regards
On Tue, Dec 15, 2009 at 4:54 AM, Jean-Francois Moine moin...@free.fr wrote:
On Tue, 15 Dec 2009 03:45:00 +
Luis Maia lm...@royalhat.org wrote:
Added extra chipset revision (sensor) to fix camera zc0301 with ID:
0ac8:301b .
Since i own one of this cameras fixed and tested it.
-
diff -uNr linux-2.6.32.1/drivers/media/video/gspca/zc3xx.c
linux-2.6.32.1-patch/drivers/media/video/gspca/zc3xx.c
--- linux-2.6.32.1/drivers/media/video/gspca/zc3xx.c 2009-12-14
17:47:25.0 +
+++ linux-2.6.32.1-patch/drivers/media/video/gspca/zc3xx.c
2009-12-15 02:42:13.0 +
@@ -6868,6 +6868,7 @@
{0x8001, 0x13},
{0x8000, 0x14}, /* CS2102K */
{0x8400, 0x15}, /* TAS5130K */
+ {0xe400, 0x15},
};
static int vga_3wr_probe(struct gspca_dev *gspca_dev)
@@ -7634,7 +7635,7 @@
{USB_DEVICE(0x0698, 0x2003)},
{USB_DEVICE(0x0ac8, 0x0301), .driver_info = SENSOR_PAS106},
{USB_DEVICE(0x0ac8, 0x0302), .driver_info = SENSOR_PAS106},
- {USB_DEVICE(0x0ac8, 0x301b)},
+ {USB_DEVICE(0x0ac8, 0x301b), .driver_info = SENSOR_PB0330},
{USB_DEVICE(0x0ac8, 0x303b)},
{USB_DEVICE(0x0ac8, 0x305b), .driver_info =
SENSOR_TAS5130C_VF0250}, {USB_DEVICE(0x0ac8, 0x307b)},
Hello Luis,
I don't understand your patch:
1) you added 0xe400 in the chipset table giving the sensor tas5130c K
2) in the device table you say that the 0ac8:301b sensor is a pb0330
(but this information is not used: the sensor type in .driver_info
may be only pas106 for sif probe or mc501cb/tas5130_vf0250 for no
probe.
What is exactly the sensor of your webcam?
--
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
--
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- gspca: added chipset revision sensor
Actually, i have not heard of other chipset's revision about task1530k
since 2008 (http://article.gmane.org/gmane.linux.drivers.spca50x.devel/2826
)
But it's possible that , there will be many others cam using that.
Luis, in fact there seem's to be a pattern against revision chipset
id - sensor, but actually, i cannot assure that there'nt an
exception. Jean, should decide on that :)
pd: Jean, I am waiting for the user that was doing the patch for the
t613 against a new sensor... :)
Best Regards
On Wed, Dec 16, 2009 at 1:34 AM, Luis Maia lm...@royalhat.org wrote:
I found an email that discussed the similar problem that my camera had,
showing up just a black screen, it's dated but i think maybe it wasn't
fully solved because there's no answer.
http://osdir.com/ml/drivers.spca50x.devel/2006-11/msg00036.html
Note the : / /Vimicro/zc3xx.h: [zcxx_probeSensor:307] sensor 3w Vga ???
0xC400
/Do you know if this was solved?!
Because i suspect that maybe there are more 0x?400 revision of the chipset.
Btw, if this is a pattern could we consider to mask the bits in retword
(retword = 0x0FFF)?
Because looking at the current table it seems to make more sense.
Best regards,
Luis Maia.
Jean-Francois Moine wrote:
On Tue, 15 Dec 2009 10:25:29 -0300
leandro Costantino lcostant...@gmail.com wrote:
Jean,
let me know , if you need to the test this patch, since i added the
tas1530k long time ago, and still have the webcam :)
Best Regards
On Tue, Dec 15, 2009 at 4:54 AM, Jean-Francois Moine
moin...@free.fr wrote:
On Tue, 15 Dec 2009 03:45:00 +
Luis Maia lm...@royalhat.org wrote:
Added extra chipset revision (sensor) to fix camera zc0301 with
ID: 0ac8:301b .
Since i own one of this cameras fixed and tested it.
-
diff -uNr linux-2.6.32.1/drivers/media/video/gspca/zc3xx.c
linux-2.6.32.1-patch/drivers/media/video/gspca/zc3xx.c
--- linux-2.6.32.1/drivers/media/video/gspca/zc3xx.c 2009-12-14
17:47:25.0 +
+++ linux-2.6.32.1-patch/drivers/media/video/gspca/zc3xx.c
2009-12-15 02:42:13.0 +
@@ -6868,6 +6868,7 @@
{0x8001, 0x13},
{0x8000, 0x14}, /* CS2102K */
{0x8400, 0x15}, /* TAS5130K */
+ {0xe400, 0x15},
};
static int vga_3wr_probe(struct gspca_dev *gspca_dev)
@@ -7634,7 +7635,7 @@
{USB_DEVICE(0x0698, 0x2003)},
{USB_DEVICE(0x0ac8, 0x0301), .driver_info = SENSOR_PAS106},
{USB_DEVICE(0x0ac8, 0x0302), .driver_info = SENSOR_PAS106},
- {USB_DEVICE(0x0ac8, 0x301b)},
+ {USB_DEVICE(0x0ac8, 0x301b), .driver_info = SENSOR_PB0330},
{USB_DEVICE(0x0ac8, 0x303b)},
{USB_DEVICE(0x0ac8, 0x305b), .driver_info =
SENSOR_TAS5130C_VF0250}, {USB_DEVICE(0x0ac8, 0x307b)},
Hello Luis and Leandro,
Thanks for the patch. Luis said his sensor is the tas5130K, so the 2nd
part of the patch is useless. But, maybe, Leandro, have you heard about
other chipset revision IDs?
Best regards.
--
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: problems compiling webcam driver
Check that videodev.ko is the last one. Are you compiling vanilla gspca drivers from the kernel? or the mercuarial version? On Mon, Dec 14, 2009 at 2:17 PM, Nicolau Werneck nwern...@gmail.com wrote: Hello. I have modified the t613 driver to support a new sensor (code 0x0802), and I am now trying to prepare a patch to submit. The problem is that now that I started to work with the driver again, I started to get this error message... Does anybody know what is this about? I already tried to switch from the 2.6.31 kernel to the 2.6.32, but the same happened. [ 1524.864013] usb 6-2: new full speed USB device using uhci_hcd and address 3 [ 1525.026046] usb 6-2: New USB device found, idVendor=17a1, idProduct=0128 [ 1525.026049] usb 6-2: New USB device strings: Mfr=32, Product=38, SerialNumber=0 [ 1525.026052] usb 6-2: Product: USB2.0 JPEG WebCam [ 1525.026054] usb 6-2: Manufacturer: TASCORP [ 1525.026131] usb 6-2: configuration #1 chosen from 1 choice [ 1525.072916] gspca_main: disagrees about version of symbol video_devdata [ 1525.072918] gspca_main: Unknown symbol video_devdata [ 1525.073060] gspca_main: disagrees about version of symbol video_unregister_device [ 1525.073062] gspca_main: Unknown symbol video_unregister_device [ 1525.073118] gspca_main: disagrees about version of symbol video_register_device [ 1525.073119] gspca_main: Unknown symbol video_register_device [ 1525.073649] gspca_t613: Unknown symbol gspca_frame_add [ 1525.073731] gspca_t613: Unknown symbol gspca_debug [ 1525.073878] gspca_t613: Unknown symbol gspca_disconnect [ 1525.073931] gspca_t613: Unknown symbol gspca_resume [ 1525.073985] gspca_t613: Unknown symbol gspca_dev_probe [ 1525.074038] gspca_t613: Unknown symbol gspca_suspend see you, ++nicolau -- Nicolau Werneck nwern...@gmail.com 1AAB 4050 1999 BDFF 4862 http://www.lti.pcs.usp.br/~nwerneck 4A33 D2B5 648B 4789 0327 Linux user #460716 -- 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 -- 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: new sensor for a t613 camera
Please, send me the patch for review :) On Tue, Nov 17, 2009 at 9:41 PM, Nicolau Werneck nwern...@gmail.com wrote: Hello, people. I did it! I looked at the log and modified the driver to support my webcam. It's working!! I'm sending an image attached. :] I'll clean up my code now, and submit a patch later. Help is appreciated, because I don't have much experience contributing to large projects... This webcam is a very cheap one, quite easy to find these days. I hope the support will be appreciated by many users. See you, ++nicolau On Fri, Nov 13, 2009 at 03:35:26PM -0500, leandro Costantino wrote: Hi Nicolau, Are you able to give me some usb traces? there's a little how to http://deaglecito.blogspot.com/2008/10/new-sensor-merge-faq-tascorp-17a10128.html here. I don't have too much time now, but i can take a look and made some changes to test and guide you. Best Regards Costantino Leandro On Fri, Nov 13, 2009 at 3:27 PM, Nicolau Werneck nwern...@gmail.com wrote: On Fri, Nov 13, 2009 at 09:04:23PM +0100, Erik Andrén wrote: 2009/11/13 Nicolau Werneck nwern...@gmail.com: Hello. I bought me a new webcam. lsusb said me it was a 17a1:0128 device, for which the gspca_t613 module is available. But it did not recognize the sensor number, 0x0802. I fiddled with the driver source code, and just made it recognize it as a 0x0803 sensor, called others in the code, and I did get images from the camera. But the colors are extremely wrong, like the contrast was set to a very high number. It's probably some soft of color encoding gone wrong... How can I start hacking this driver to try to make my camera work under Linux? If possible you could open the camera to investigate if there is anything printed on the sensor chip. This might give you a clue to what sensor it is. Thanks for redirecting me. I opened it (So much for the warranty seal...), but there is just huge black blob of goo over the chip, as usual these days. ++nicolau -- Nicolau Werneck nwern...@gmail.com 1AAB 4050 1999 BDFF 4862 http://www.lti.pcs.usp.br/~nwerneck 4A33 D2B5 648B 4789 0327 Linux user #460716 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkr9wUIACgkQ0rVki0eJAycSegCfRQyYN54CNH2thIo/PHBnVaL9 avAAoMe6ihIbvX23kM1ir2sJK32q6jxm =HI4V -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 -- Nicolau Werneck nwern...@gmail.com 1AAB 4050 1999 BDFF 4862 http://www.lti.pcs.usp.br/~nwerneck 4A33 D2B5 648B 4789 0327 Linux user #460716 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAksDCmgACgkQ0rVki0eJAyfs3QCeJz8skhHixReBoIShZeRiKafv IQ0AoIi24OnTEPe77UUhw8U6RztAMsjO =5NY4 -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: image quality of Labtec Webcam 2200
Actually it based on pac7302. Pac7311/02 also has support ( since gspca1 ). I checked some old logs of the pac, and the driver init for 7302 seems ok. The ff ff ff sequence, seems to been taken in account on conversion. (libv4lconvert) /* Special Pixart versions of the *_nbits functions, these remove the special ff ff ff xx sequences pixart cams insert from the bitstream */ #define pixart_fill_nbits(reservoir,nbits_in_reservoir,stream,nbits_wanted) \ This is really a tricky cam. I be back on windows to do further test. pd: Nemeth, i could reproduce your problems now. 2009/9/13 Németh Márton nm...@freemail.hu: Jean-Francois Moine wrote: On Fri, 11 Sep 2009 09:09:20 +0200 Németh Márton nm...@freemail.hu wrote: You can find my results at http://v4l-test.sourceforge.net/results/test-20090911/index.html There are three types of problems: a) Sometimes the picture contains a 8x8 pixel error, like in image #9 http://v4l-test.sourceforge.net/results/test-20090911/index.html#img9 b) Sometimes the brightness of the half picture is changed, like in images #7, #36 and #37 http://v4l-test.sourceforge.net/results/test-20090911/index.html#img7 http://v4l-test.sourceforge.net/results/test-20090911/index.html#img00036 http://v4l-test.sourceforge.net/results/test-20090911/index.html#img00037 c) Sometimes the libv4l cannot convert the raw image and the errno is set to EAGAIN (11), for example image #1, #2 and #3 Do you know how can I fix these problems? The error EAGAIN is normal when decoding pac7311 images, because they are rotated 90°. But this error should occur one time only. I have the feeling that the Labtec Webcam 2200 is not based on the PAC7311 but on PAC7312. The PAC7312 also contains a microphone input and the Labtec Webcam 2200 also have a built-in microphone. See http://www.pixart.com.tw/productsditel.asp?ToPage=1productclassify_id=12productclassify2_id=33 for the datasheets. See also http://labtec.com/index.cfm/gear/details/EUR/EN,crid=30,contentid=761 . I looked at the raw image #1, and it seems that there are JPEG errors inside (sequences ff ff). There should be a problem in the pac7311 driver. Hans, may you confirm? -- 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: image quality of Labtec Webcam 2200
Nice, i will take a look.
Anyway, be aware, that the conversion error, is something expected
on pac7311, in fact, Hans have commented that on the libv4lconvert.
..
if (result) {
/* Pixart webcam's seem to regulary generate corrupt frames, which
are best thrown away to avoid flashes in the video stream. Tell
the upper layer this is an intermediate fault and it should try
again with a new buffer by setting errno to EAGAIN */
if (src_pix_fmt == V4L2_PIX_FMT_PJPG ||
data-flags V4LCONVERT_IS_SN9C20X) {
V4LCONVERT_ERR(decompressing JPEG: %s,
tinyjpeg_get_errorstring(data-jdec));
errno = EAGAIN;
return -1;
That's the result of the EAGAIN.
About, the half brightness picture, did that happens when autogain is off?
Best Regards
On Sat, Sep 12, 2009 at 2:16 AM, Németh Márton nm...@freemail.hu wrote:
Hello,
thank you for looking at this topic.
leandro Costantino wrote:
Hi ,
i tested it with 2.6.31-rc9 libvl 0.6.1 + svv and cannot reproduce.
301147.626826] gspca: probing 093a:2626
[301147.641578] gspca: probe ok
[301147.641607] gspca: probing 093a:2626
[301147.641770] gspca: probing 093a:2626
[301147.641829] usbcore: registered new interface driver pac7311
[301147.641835] pac7311: registered
I have the same dmesg output. My Labtec Webcam 2200 has the following labels
on the cable:
M/N: V-UCE52
P/N: 860-73
PID: CE73902
Maybe there is more than one revision of the Labtec Webcam 2200 and I have
one with a different hardware/firmware inside?
Could you try testing with svv.c app?
I used a bit modified svv.c to create the measurement result. The
modifications are to create the output HTML report and save the raw
and the BMP images. The display is not correct because I changed
the format from V4L2_PIX_FMT_RGB24 to V4L2_PIX_FMT_BGR24 to easily
save the result to BMP. The source code quality is not the best,
I am sorry about that, but I can still attach my source code which I
modified a little bit since my last report.
pd: quality is not the best, but works ok. Seem that the format is not
the proper or expected pjpeg on your streaming.
Do you think about USB transfer problem?
Regards,
Márton Németh
2009/9/11 Németh Márton nm...@freemail.hu:
Márton Németh wrote:
Hi,
I have a Labtec Webcam 2200 and I have problems with the image quality
with Linux 2.6.31 + libv4l 0.6.1. I made some experiments and stored
each captured image as raw data and when libv4l was able to convert
then I also stored the result as bmp.
You can find my results at
http://v4l-test.sourceforge.net/results/test-20090911/index.html
There are three types of problems:
a) Sometimes the picture contains a 8x8 pixel error, like in image #9
http://v4l-test.sourceforge.net/results/test-20090911/index.html#img9
b) Sometimes the brightness of the half picture is changed, like in
images #7, #36 and #37
http://v4l-test.sourceforge.net/results/test-20090911/index.html#img7
http://v4l-test.sourceforge.net/results/test-20090911/index.html#img00036
http://v4l-test.sourceforge.net/results/test-20090911/index.html#img00037
c) Sometimes the libv4l cannot convert the raw image and the errno
is set to EAGAIN (11), for example image #1, #2 and #3
Do you know how can I fix these problems?
I investigated the c) point a little bit. When I get a negative return
value
from the v4lconvert_convert() function then I print out the error
message what the
v4lconvert_get_error_message() function returns. With the result log file
I executed a grep v4l-convert |sort |uniq command. All the error
messages are
coming from the tinyjpeg.c (Small jpeg decoder library):
v4l-convert: error decompressing JPEG: error: more then 63 AC components
(65) in huffman unit
v4l-convert: error decompressing JPEG: error: more then 63 AC components
(66) in huffman unit
v4l-convert: error decompressing JPEG: error: more then 63 AC components
(67) in huffman unit
v4l-convert: error decompressing JPEG: error: more then 63 AC components
(68) in huffman unit
v4l-convert: error decompressing JPEG: error: more then 63 AC components
(69) in huffman unit
v4l-convert: error decompressing JPEG: error: more then 63 AC components
(70) in huffman unit
v4l-convert: error decompressing JPEG: error: more then 63 AC components
(71) in huffman unit
v4l-convert: error decompressing JPEG: error: more then 63 AC components
(72) in huffman unit
v4l-convert: error decompressing JPEG: error: more then 63 AC components
(73) in huffman unit
v4l-convert: error decompressing JPEG: error: more then 63 AC components
(75) in huffman unit
v4l-convert: error decompressing JPEG: error: more then 63 AC components
(76) in huffman unit
v4l-convert: error decompressing JPEG: Pixart JPEG error
Re: image quality of Labtec Webcam 2200
Hi , i tested it with 2.6.31-rc9 libvl 0.6.1 + svv and cannot reproduce. 301147.626826] gspca: probing 093a:2626 [301147.641578] gspca: probe ok [301147.641607] gspca: probing 093a:2626 [301147.641770] gspca: probing 093a:2626 [301147.641829] usbcore: registered new interface driver pac7311 [301147.641835] pac7311: registered Could you try testing with svv.c app? pd: quality is not the best, but works ok. Seem that the format is not the proper or expected pjpeg on your streaming. 2009/9/11 Németh Márton nm...@freemail.hu: Márton Németh wrote: Hi, I have a Labtec Webcam 2200 and I have problems with the image quality with Linux 2.6.31 + libv4l 0.6.1. I made some experiments and stored each captured image as raw data and when libv4l was able to convert then I also stored the result as bmp. You can find my results at http://v4l-test.sourceforge.net/results/test-20090911/index.html There are three types of problems: a) Sometimes the picture contains a 8x8 pixel error, like in image #9 http://v4l-test.sourceforge.net/results/test-20090911/index.html#img9 b) Sometimes the brightness of the half picture is changed, like in images #7, #36 and #37 http://v4l-test.sourceforge.net/results/test-20090911/index.html#img7 http://v4l-test.sourceforge.net/results/test-20090911/index.html#img00036 http://v4l-test.sourceforge.net/results/test-20090911/index.html#img00037 c) Sometimes the libv4l cannot convert the raw image and the errno is set to EAGAIN (11), for example image #1, #2 and #3 Do you know how can I fix these problems? I investigated the c) point a little bit. When I get a negative return value from the v4lconvert_convert() function then I print out the error message what the v4lconvert_get_error_message() function returns. With the result log file I executed a grep v4l-convert |sort |uniq command. All the error messages are coming from the tinyjpeg.c (Small jpeg decoder library): v4l-convert: error decompressing JPEG: error: more then 63 AC components (65) in huffman unit v4l-convert: error decompressing JPEG: error: more then 63 AC components (66) in huffman unit v4l-convert: error decompressing JPEG: error: more then 63 AC components (67) in huffman unit v4l-convert: error decompressing JPEG: error: more then 63 AC components (68) in huffman unit v4l-convert: error decompressing JPEG: error: more then 63 AC components (69) in huffman unit v4l-convert: error decompressing JPEG: error: more then 63 AC components (70) in huffman unit v4l-convert: error decompressing JPEG: error: more then 63 AC components (71) in huffman unit v4l-convert: error decompressing JPEG: error: more then 63 AC components (72) in huffman unit v4l-convert: error decompressing JPEG: error: more then 63 AC components (73) in huffman unit v4l-convert: error decompressing JPEG: error: more then 63 AC components (75) in huffman unit v4l-convert: error decompressing JPEG: error: more then 63 AC components (76) in huffman unit v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: 0x00 v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: 0x01 v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: 0x02 v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: 0x04 v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: 0x08 v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: 0x09 v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: 0x0a v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: 0x10 v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: 0x12 v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: 0x14 v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: 0x1a v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: 0x1b v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: 0x1c v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: 0x1f v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: 0x80 v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: 0x82 v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: 0x87 v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: 0x88 v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: 0x89 v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: 0x8a v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: 0x8b v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: 0x8c v4l-convert: error decompressing JPEG: Pixart JPEG
Re: image quality of Labtec Webcam 2200
Also , about the negative value. It happens to when using Pac7311 on libv4l_convert. Usually it an -EAGAIN, that should be ignored. svv application, just ignore that, and another apps take in account. But would be nice to re test your webcam to find where the real problem is. Best Regards 2009/9/11 Németh Márton nm...@freemail.hu: Márton Németh wrote: Hi, I have a Labtec Webcam 2200 and I have problems with the image quality with Linux 2.6.31 + libv4l 0.6.1. I made some experiments and stored each captured image as raw data and when libv4l was able to convert then I also stored the result as bmp. You can find my results at http://v4l-test.sourceforge.net/results/test-20090911/index.html There are three types of problems: a) Sometimes the picture contains a 8x8 pixel error, like in image #9 http://v4l-test.sourceforge.net/results/test-20090911/index.html#img9 b) Sometimes the brightness of the half picture is changed, like in images #7, #36 and #37 http://v4l-test.sourceforge.net/results/test-20090911/index.html#img7 http://v4l-test.sourceforge.net/results/test-20090911/index.html#img00036 http://v4l-test.sourceforge.net/results/test-20090911/index.html#img00037 c) Sometimes the libv4l cannot convert the raw image and the errno is set to EAGAIN (11), for example image #1, #2 and #3 Do you know how can I fix these problems? I investigated the c) point a little bit. When I get a negative return value from the v4lconvert_convert() function then I print out the error message what the v4lconvert_get_error_message() function returns. With the result log file I executed a grep v4l-convert |sort |uniq command. All the error messages are coming from the tinyjpeg.c (Small jpeg decoder library): v4l-convert: error decompressing JPEG: error: more then 63 AC components (65) in huffman unit v4l-convert: error decompressing JPEG: error: more then 63 AC components (66) in huffman unit v4l-convert: error decompressing JPEG: error: more then 63 AC components (67) in huffman unit v4l-convert: error decompressing JPEG: error: more then 63 AC components (68) in huffman unit v4l-convert: error decompressing JPEG: error: more then 63 AC components (69) in huffman unit v4l-convert: error decompressing JPEG: error: more then 63 AC components (70) in huffman unit v4l-convert: error decompressing JPEG: error: more then 63 AC components (71) in huffman unit v4l-convert: error decompressing JPEG: error: more then 63 AC components (72) in huffman unit v4l-convert: error decompressing JPEG: error: more then 63 AC components (73) in huffman unit v4l-convert: error decompressing JPEG: error: more then 63 AC components (75) in huffman unit v4l-convert: error decompressing JPEG: error: more then 63 AC components (76) in huffman unit v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: 0x00 v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: 0x01 v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: 0x02 v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: 0x04 v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: 0x08 v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: 0x09 v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: 0x0a v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: 0x10 v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: 0x12 v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: 0x14 v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: 0x1a v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: 0x1b v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: 0x1c v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: 0x1f v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: 0x80 v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: 0x82 v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: 0x87 v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: 0x88 v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: 0x89 v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: 0x8a v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: 0x8b v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: 0x8c v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: 0x8d v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: 0x8e v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker:
Re: [PATCH 0/2] gspca sn9c20x subdriver rev2
Hi, shouldn't there be a check when allocating jpg_hdr? or i am missing something? sd-jpeg_hdr = kmalloc(JPEG_HDR_SZ, GFP_KERNEL); jpeg_define(sd-jpeg_hdr, height, width, 0x21); jpeg_set_qual(sd-jpeg_hdr, sd-quality); Best Regards. Nice to see microdia project here :) On Sat, Jul 18, 2009 at 11:19 AM, Brian Johnsonbrij...@gmail.com wrote: - in the 1st patch, in gspca.c, why is the get_chip_ident check needed in vidioc_g_register / vidioc_s_register)? According the the current v4l2 spec regarding the set and get register ioctls drivers that support them must also support the get chip ident ioctl. As such in the vidioc_s/g_register ioctls I do the check to ensure that the driver also defines the get_chip_ident ioctl. Brian Johnson -- 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 -- 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: working on webcam driver
Hi Mark, just searching 0c45:612a gspca could save you lot of time. I suppose you were looking at the old gspca homepage, because it listed on Jean F. Moine site http://moinejf.free.fr/webcam.html ( it dont know even it that page if still updated ) About the gstreamer, what kind of troubles are you having?. It's the webcam streaming? Did you follow the steps using libv4lconvert?. I wrote that patch a year ago, so , if there's any problem let me know. If you need help, about the lib4vlconvert thing, look at deaglecito.blogspot.com Best Regards Costantino Leandro On Sun, May 17, 2009 at 12:08 PM, MK halfcountp...@intergate.com wrote: Thanks much for the feedback! Here's what happened: Because the vendor id (0c45) is listed by the gspca website but not the product (612a), I decided to try inserting the id into one of the drivers/media/video/gspca. When I actually grepped (had not grepped the tree itself yet), low and behold 612a is in sonixj. The module compiles and responds to the camera, although the results in gstreamer, et. al, are disappointing -- the camera is not really usable, I suspect from the output it is the kernel driver, but I am not sure. Since I didn't write this stuff, I think working alone it will be more trouble than it is worth to track the problem down, esp. if this is mostly a problem with an (obscure) inexpensive item that few linux users actually possess. So, I am going to cut my loses early on this project and cop out. I've learned a bunch about the kernel and in the process written some nifty little char drivers that are probably more useful to me than a webcam anyway. I think my time would be better spent on other things, eg, I might become useful in someone else's (more significant) linux kernel/driver project. I will have a look around. But thanks again! You were much nicer than mr Greg Kroah-Hartman ;) :0 Sincerely, Mark Eriksen (getting his feet wet) -- video4linux-list mailing list Unsubscribe mailto:video4linux-list-requ...@redhat.com?subject=unsubscribe https://www.redhat.com/mailman/listinfo/video4linux-list -- 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
