Ok both i've submitted a patch for both vlc and amsn to their respective devel mailing lists in regards to this issue i'll do kde's tomorrow sometime.
The reason i originally did tie AWB to the red/blue gains is that logically that is how you would expect it to work. If i have the driver managing my white balance i would also expect the color gains to be unavailable. Even if yes technically because one is using the sensor and the other the bridge you can modify the color gains even when AWB is in effect. It would also be conceivable since we get AWB window data back from the bridge to write a similar function to the software based ae function to implement whitebalanace calculations for sensors that don't support whitebalance such as the micron sensors without an IFP. If we ever did this then at least for some sensors the AWB and color gains would be connected. Hmm i don't get a lockup on my system when hue drops below 40. does it still happen if you set it using sysfs to less then 40? As for the wrapper functions yes we should probably be able to get rid of them just fine. The only real reason i could think of to keep them is that a function name like set_contrast is somewhat more obvious then set_optical_parameters, but i don't think that by itself should justify keeping the them either. On Fri, Mar 20, 2009 at 4:22 PM, Josua Grawitter <[email protected]> wrote: > Am Freitag 20 März 2009 10:05:06 schrieb Brian Johnson: >> Ok just took a quick look at amsn source and yes the code for setting >> an attribute is definitely broken it checks the value tht you are >> setting for a range of 0 - 65535. this is definitely wrong as av4l2 >> control value is first of all signed and second of all it should be >> using its defined min/max values anyways. I attached a quick patch >> that fixes this issue with amsn in case anyone is interested. >> >> Also kopete seems to have two issues one it appears it also doesn't >> bother to consider that a control value can be negative and kopete >> actually natively knows bayer format whcih unless i use somethign like >> libv4l it will use by default. and none of the controls that use our >> bridges color matrix (hue/sat/contrast/brightness) work when using >> bayer since it is not being converted to YUV. this is one reason you >> should not use bayer unless there is no other choice. >> >> Also I'm of the mind that we should not modify our driver in order to >> fix broken applications. The more correct thing will be to patch the >> applications to properly follow v4l2 specs. In this case allow >> controls with negative values. >> > > I just did some testing: > 1. Somehow green/blue gain are still locked if AWB is enabled. I thought my > patch fixed that but apparently it didn't. > 2. Saturation, hue, etc work as expected, however ... > 3. If saturation is set to less than circa 40 my computer locks up. I suspect > the framerate drops and the buffer is unhappy but I can't tell exactly because > there is no kernel-oops and dmesg looks fine after I reboot. > 4. Why do we keep a wrapper function which calls wrapper functions through a > set of pointers which in the end all end up with the same functions - for hue, > saturation, blue/red gain, brightness, contrast and gamma there is only the > bridge functions so why not call them directly? And why not call > "sn9c20x_set_optical_parameters()" directly? > I think clearing that mess will make the module and the struct usb_sn9c20x at > least a bit smaller and also the code clearer. I'll post a patch once the > style isses are fixed. > > GWater > > > --~--~---------~--~----~------------~-------~--~----~ Lets make microdia webcams plug'n play, (currently plug'n pray) To post to this group, send email to [email protected] Visit us online https://groups.google.com/group/microdia -~----------~----~----~----~------~----~------~--~---
