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 > > --~--~---------~--~----~------------~-------~--~----~ > 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 > -~----------~----~----~----~------~----~------~--~---
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
signature.asc
Description: This is a digitally signed message part.
