Re: [Spca50x-devs] PATCH: gspca-mercurial OV7630 light frequency filter
- Date: Thu, 17 Jul 2008 09:14:45 +0200
- From: Hans de Goede <j.w.r.degoede@xxxxxx>
- Subject: Re: [Spca50x-devs] PATCH: gspca-mercurial OV7630 light frequency filter
Andoni Zubimendi wrote:
> I'm sorry, but the previous patch had an error an didn't set the LSB bits of
I had already seen that the ov7630 has 2 additional bits, but I don't think
this is necessary as our exposure ctrl as seen by applications / the
autoexposure code goes from 0-255, so we don't need this additional resolution
as we won't use it. So my idea was to just leave this 2 bits at there defaults.
Also note that if we do keep your code in place that reg10max then needs to be
multiplied by 4 in the ov7630 case. the 0x41 reg10max, is really the max for
reg10, so for the 8 MSB's if we right shift the value by 2 before putting it in
reg10, we thus need to multiply reg10max by 4 to compensate for the right shift.
Also I wonder if you've tested this new patch, if reg10max is set correctly you
should see a very smooth exposure range, because when the exposure setting
increases so much that the framerate halves (from 30 to 15 fps) to be able to
provide the new wanted exposure, the reg10 setting becomes about half of
reg10max so that the exposure hardly changes at all. I've tested this by
replacing SID_EXPOSURE with SID_CONTRAST as most apps have a way to control
contrast, I then used camorama, gave the contrast slider focus by clicking on
it and changed it one step at a time with the left / right arrows. When it goes
from 16 to 17 you should see the frame rate drop from 30 to 15 (camorama also
shows the framerate) which normally would cause a huge difference in exposure,
but if you have reg10max correct for the ov7630 the step should be quite small.
Do not use ekiga to try these kind of things, ekiga's brightness / contrast
controls are buggy.
Talking about testing, now that we hopefully have the correct code for getting
the average luminance from the frame header for the sn9c103, autoexposure
should work, have you tested this?
> Here's a new patch. Additionaly, I've cleanup the initialization code of the
> OV7630 sensor.
Thanks I had doing this on my todo list as I already noticed that all the
registers touched by the i2c init code not common to both the ov7630 and the
ov7630_3 were i2c registers which we know control through v4l2 ctrl's and thus
setting them at init is useless as we will immediately overwrite them with our
Note that you can even remove the last bit of non common init code, the only
bits which are changed from the reset defaults by the init code are actually
MSB's of the framerate adjust register which we set in the powerline frequency
control, and we do not need to touch these, as we never want to adjust the
framerate by so much that we need the MSB's .
I don't know why the windows driver is touching these MSB's it is basicly
slowing the framerate by 2/3ths for some unknown reason.
Also note that the non-common code for the ov7660 (without the _3) also is only
touching registers which we handle with v4l2 ctrl's so that can be removed to.
After which we can merge the 2 ov7660 types back into one type, only having
different init_code for the bridge when using an 101/102 versus the 103 and not
having different code for the sensor, as things should be.
Once this is done, the whole ov7630_3 abomination can be removed, and which
init registers to send to the bridge can be decided based upon sd->fr_h_size,
or we can add an sd->bridge_type variable.
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
Spca50x-devs mailing list