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 : > 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, 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 white balance on a t613 camera
Yes, as wrote in the code, it tied to whitebalance. Also note that , as Jean wrote, there's are many different values wrote on some registers, that we don't really know what they are used for, so, i would like to go for the most non intrusive option, since, some of this whitebalance regs, have been adjusted time to time to meet other t613 users requirment's, and maybe implementing the r/b balance would be the way to go. If you want, i can write it so you can test it, or if you prefeer you can take a look at http://linuxtv.org/hg/~jfrancois/gspca/file/21f2eeb240db/linux/drivers/media/video/gspca/sonixj.c at how its done as an example. Since i only had this webcam for 1 week, i always relay on the some group of users that are willing to test each change always. Best Regadrs. Costantino Leandro On Wed, Jan 27, 2010 at 3:37 PM, Jean-Francois Moine wrote: > On Wed, 27 Jan 2010 15:17:53 -0200 > Nicolau Werneck wrote: > >> Answering my own question, and also a question in the t613 source >> code... >> >> Yes, the need for the "reg_w(gspca_dev, 0x2087);", 0x2088 and 0x2089 >> commands are definitely tied to the white balance. These three set up >> the default values I found out. And (X << 8 + 87) sets up the red >> channel parameter in general, and 88 is for green and 89 for blue. >> >> That means I can already just play with them and see what happens. My >> personal problem is that I bought this new lens, and the image is way >> too bright, and changing that seems to help. But I would like to offer >> these as parameters the user can set using v4l2 programs. I can try >> making that big change myself, but help from a more experienced >> developer would be certainly much appreciated!... > > Hello Nicolau, > > The white balance is set in setwhitebalance(). Four registers are > changed: 87, 88, 89 and 80. > > Looking at the traces I have, these 4 registers are loaded together only > one time in an exchange at startup time. Then, the white balance > control adjusts only blue and red values while reloading the same value > for the green register (that's what is done for other webcams), and the > register 80 is not touched. In the different traces, the register 80 > may be initialized to various values as 3c, ac or 38 and it is not > touched later. I do not know what it is used for. > > I may also notice that the green value in the white balance exchanges > may have an other value than the default 20. I do not know which is the > associated control in the ms-win driver. If it is exposure, you are > done. So, one trivial patch is: > > - add the exposure control with min: 0x10, max: 0x40, def: 0x20. > > - modify the whitebalance control with min: -16, max +16, def:0. > > - there is no function setexposure() because the exposure is the value > of green register. Both controls exposure and white balance call the > function setwhitebalance(). > > - in the function setwhitebalance(), set the green value to the > exposure, the red value to (exposure + whitebalance) and blue value > to (exposure - whitebalance) and load only the registers 87, 88 and > 89. > > An other way could be to implement the blue and red balances in the > same scheme, and to remove the whitebalance. > > 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 > -- 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 wrote: > On Tue, 26 Jan 2010 15:00:53 -0200 > Nicolau Werneck 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 : > 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 >
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 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
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 wrote:
>> On Fri, 18 Dec 2009 16:46:04 -0200
>> Nicolau Werneck 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: ', 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, sens
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 wrote:
> On Fri, 18 Dec 2009 16:46:04 -0200
> Nicolau Werneck 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: ', 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 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
> 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 po
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 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 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
>>> wrote:
>>>
>>>>
>>>> On Tue, 15 Dec 2009 03:45:00 +
>>>> Luis Maia 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: 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 wrote:
> On Tue, 15 Dec 2009 03:45:00 +
> Luis Maia 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: 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 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 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 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 wrote: >> > On Fri, Nov 13, 2009 at 09:04:23PM +0100, Erik Andrén wrote: >> >> 2009/11/13 Nicolau Werneck : >> >> > 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 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 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: new sensor for a t613 camera
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 wrote: > On Fri, Nov 13, 2009 at 09:04:23PM +0100, Erik Andrén wrote: >> 2009/11/13 Nicolau Werneck : >> > 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 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
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 : > Jean-Francois Moine wrote: >> On Fri, 11 Sep 2009 09:09:20 +0200 >> Németh Márton 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=1&productclassify_id=12&productclassify2_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 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 :
>>> >> 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
>>> >>
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 : > 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: inval
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 : > 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 JPE
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 Johnson 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 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
