Re: 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
> AEC.
> 

Hi,

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 
ctrl settings.

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.

Regards,

Hans


-------------------------------------------------------------------------
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
http://moblin-contest.org/redirect.php?banner_id=100&url=/