Thanks a lot Brian. That is new for me. I found this pl script and will be clear all warnings.
Brian Johnson wrote: > checkpatch.pl is a script included with the linux kernel that will > check a patch to make sure it uses the proper style according to the > linux kernel coding style guidlines. you should run it against the > latest version of the hue_sat_range.patch and make sure you fix any > errors it reports. its located in the scripts directory of the kernel > sources and is run like the following > > # checkpatch.pl --no-tree <path/to/patch> > > 2009/3/23 Boris Borisov <[email protected]>: > >> Maybe I lost coup of old mail from group and can't understand what you mind >> "checkpatch.pl errors fixed " >> I have only the my and you last patch. Based on current (reverted without >> saturation) git. If I clone the git and apply the patch (my for sat/hue/b/c, >> and you for negative value of hue) file name hue_set_range.patch all seems >> ok. >> Have your permission to do I commitment or you will do. >> For me is very hart to do any improvement if I not have variant for fast >> reverting. >> >> Brian Johnson wrote: >> >> So its calling set=optical five times when you change saturation via >> sysfs? I haven:t been able to get it to do that for me, wonder whats >> different. >> >> Also boris do you have a cleanedup version of the atch that has the >> checkpatch.pl errors fixed? >> >> On Sun, Mar 22, 2009 at 3:37 PM, Josua Grawitter >> <[email protected]> wrote: >> >> >> Am Sonntag 22 März 2009 14:34:08 schrieb Boris Borisov: >> >> >> Josua Grawitter wrote: >> >> >> Am Samstag 21 Mдrz 2009 08:23:26 schrieb Brian Johnson: >> >> >> 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 >> >> >> yes, the computer locks up whether I set saturation via v4l-ioctl or >> sysfs. >> >> Here's what dmesg tells me: >> usb 1-4: new high speed USB device using ehci_hcd and address 4 >> usb 1-4: configuration #1 chosen from 1 choice >> usb 1-4: New USB device found, idVendor=0c45, idProduct=624e >> usb 1-4: New USB device strings: Mfr=0, Product=1, SerialNumber=0 >> usb 1-4: Product: USB20 Camera >> sn9c20x: SN9C20X USB 2.0 Webcam - 0C45:624E plugged-in. >> sn9c20x: Detected SOI968 Sensor. >> sn9c20x: Webcam device 0C45:624E is now controlling video device >> /dev/video0 sn9c20x: Hue Value: 180 >> sn9c20x: Hue vsettings.hue: 180 >> sn9c20x: Hue Value: 180 >> sn9c20x: Hue vsettings.hue: 180 >> sn9c20x: Hue Value: 180 >> sn9c20x: Hue vsettings.hue: 180 >> sn9c20x: Hue Value: 180 >> sn9c20x: Hue vsettings.hue: 180 >> sn9c20x: Using yuv420 output format >> usbcore: registered new interface driver sn9c20x >> sn9c20x: SN9C20x USB 2.0 Webcam Driver v2009.01 loaded >> sn9c20x: Hue Value: 180 >> sn9c20x: Hue vsettings.hue: 180 >> sn9c20x: Hue Value: 180 >> sn9c20x: Hue vsettings.hue: 180 >> sn9c20x: Hue Value: 180 >> sn9c20x: Hue vsettings.hue: 180 >> sn9c20x: Hue Value: 180 >> sn9c20x: Hue vsettings.hue: 180 >> sn9c20x: Hue Value: 180 >> sn9c20x: Hue vsettings.hue: 180 >> >> Note: I set saturation only once. Still it seems optical_parameters was >> called 5 times. >> >> GWater >> >> >> Maybe the problem is in userland program. With amsn is call not >> immediately after slide the sliders - that provoke a little delay on >> camera reaction. >> >> >> >> My Konsole doesn't delay - I used sysfs. >> >> >> 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 -~----------~----~----~----~------~----~------~--~---
