Re: [PATCH] Fix wrong register mask in gspca/sonixj.c

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello, Jean-François,

I downloaded the tarball you recommended, compiled it and it works nicely.

The original problem also happened with this package. Playing around
with reg17 at some points, and looking the code before the commit of 2010-12-21, I could manage to work around the problem.

Only to remember, in kernel version 2.6.37.6 the webcam became very dark (I could only see things like a 60 W incandescent lamp, one meter long, or things like clear blue sky). It seemed there was some problems with auto-exposure, auto-gain or other similar.

However, the difference which effectively changed the things is the value which reg17 carries after line 2535 of gspca_sonixj.c (now referring to the "tarball" code).

I noticed that in 640x480 the device worked fine, but in 320x240 and 160x120 it didn't (I mean: the image is dark). Or'ing reg17 with 0x04 in line 2535 (as it's currently done for VGA) is sufficient to make the webcam work again. The change could be like that:

diff --git a/build/sonixj.c b/build/sonixj.c
index afde673..802dbfa 100644
--- a/build/sonixj.c
+++ b/build/sonixj.c
@@ -2532,6 +2532,10 @@ static int sd_start(struct gspca_dev *gspca_dev)
                        reg17 &= ~MCK_SIZE_MASK;
                        reg17 |= 0x04;          /* clock / 4 */
                }
+               else {                          /* if 320x240 || 160x120 */
+                       reg17 &= ~MCK_SIZE_MASK;
+                       reg17 |= 0x04;
+               }
                break;
        case SENSOR_OV7630:
                init = ov7630_sensor_param1;

However, the frame rates get limited to 10 fps. Without that change, and in 320x240 and 160x120, they reach 20 fps (of darkness).

I can't see what or'ing that register means, and what's the relationship between this and the webcam darkness. It seems that these bits control some kind of clock; this can be read in the program comments. One other argument in favour of this assumption is the fact that the frame rate changes accordingly to the value of these bits. But I can't see how this relates to exposure.

For my purposes, I'll stay with that change; it's sufficient for my purposes. If you know what I did, please advise me. :-)

Thanks for your help,

Luiz




--- Em sex, 15/7/11, Jean-Francois Moine <moinejf@xxxxxxx> escreveu:

> De: Jean-Francois Moine <moinejf@xxxxxxx>
> Assunto: Re: [PATCH] Fix wrong register mask in gspca/sonixj.c
> Para: "Luiz Ramos" <lramos.prof@xxxxxxxxxxxx>
> Cc: linux-media@xxxxxxxxxxxxxxx
> Data: Sexta-feira, 15 de Julho de 2011, 14:44
> On Fri, 15 Jul 2011 02:57:43 -0700
> (PDT)
> Luiz Ramos <lramos.prof@xxxxxxxxxxxx>
> wrote:
> 
> > Ok, I'm now grabbing this tarball:
> > http://moinejf.free.fr/gspca-2.13.2.tar.gz.
> > 
> > The site also features a (some) git repository(ies)
> but I understood
> > you mean the test version, is it right?
> 
> Yes. The tarball is simpler to compile and install.
> 
> -- 
> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux