brightness and contrast really should be set at the same time since all these controls use the color matrix its much easier to just calculate the new amtrix values and set them all at once. Also i'm really not sure what could be so performance hungry in this function since its just doing array lookups and bit shifitng. I'm curious have you tried disabling all the callbacks for the optical controls but that saturation one and seeing if it still hangs?
On Wed, Mar 25, 2009 at 6:26 PM, Gray Water <[email protected]> wrote: > Maybe there is a way we could find a compromise: > Brightness and contrast get their own functions back. optical_parameters > just reads out the values for the affected registers. This way we can at > least reduce the number of times optical_parameters is executed. > > Performance: > My assumption ("optical_parameters is perfrmance hungry") is based solely > upn my experience uring the testing. I have no idea how the CPU's or the C > languages internals work and can therefore not point the finger at a > specific piece of code. Does typecasting involve a lot of calculation? > > GWater > > 2009/3/25 Boris Borisov <[email protected]> >> >> As global the function is very simple just a bit operation and I not found >> hungry code. >> Also strange situation is, if I set the parameters out of wrapper function >> and call set_optical.... then the parameters is not changed. >> On current version present in git the set contrast is call 2 times. And >> that is reason for call 4 times if function for brightness, contrast. hue, >> saturation is one. Multiple calls is happened for mplayer 2 times and for >> kopette 8 times. Not for ekiga, skype, amsn. >> I'm little bit confused. >> Mplayer log >> Mar 25 21:58:33 shemet sn9c20x: Contrast is set >> Mar 25 21:58:33 shemet sn9c20x: Gama is set >> Mar 25 21:58:33 shemet sn9c20x: Sharpness is set >> Mar 25 21:58:33 shemet sn9c20x: Red gain is set >> Mar 25 21:58:33 shemet sn9c20x: Blue gain is set >> Mar 25 21:58:33 shemet sn9c20x: Using yuv420 output format >> Mar 25 21:58:33 shemet driver: '2-4:1.0': driver_bound: bound to device >> 'sn9c20x' >> Mar 25 21:58:33 shemet bus: 'usb': really_probe: bound device 2-4:1.0 to >> driver sn9c20x >> Mar 25 21:58:33 shemet usbcore: registered new interface driver sn9c20x >> Mar 25 21:58:33 shemet sn9c20x: SN9C20x USB 2.0 Webcam Driver v2009.01 >> loaded >> >> >> Mar 25 21:58:46 shemet sn9c20x: Contrast is set >> Mar 25 21:58:46 shemet sn9c20x: Contrast is set >> Mar 25 21:58:47 shemet device: 'usbdev2.4_ep81': device_unregister >> Mar 25 21:58:47 shemet PM: Removing info for No Bus:usbdev2.4_ep81 >> >> Kopete log >> Mar 25 22:47:48 shemet sn9c20x: Using yuv420 output format >> Mar 25 22:47:48 shemet sn9c20x: Using yuv420 output format >> Mar 25 22:47:48 shemet sn9c20x: Using raw output format >> Mar 25 22:47:48 shemet sn9c20x: Using yuv420 output format >> Mar 25 22:47:48 shemet sn9c20x: Contrast is set >> Mar 25 22:47:48 shemet sn9c20x: Contrast is set >> Mar 25 22:47:48 shemet sn9c20x: Gama is set >> Mar 25 22:47:48 shemet sn9c20x: Contrast is set >> Mar 25 22:47:48 shemet sn9c20x: Contrast is set >> Mar 25 22:47:48 shemet sn9c20x: Gama is set >> Mar 25 22:47:48 shemet sn9c20x: Contrast is set >> Mar 25 22:47:48 shemet sn9c20x: Contrast is set >> Mar 25 22:47:48 shemet sn9c20x: Using yuv420 output format >> Mar 25 22:47:48 shemet sn9c20x: Contrast is set >> Mar 25 22:47:48 shemet sn9c20x: Contrast is set >> >> Brian Johnson wrote: >> >> It also wasn't committed due to not having the checkpatch.pl errors fixed >> yet. >> >> >> Do you know what exactly is so performance hungry in regards to >> set_optical_parameters? >> >> Also how would removing the wrappers fix it from being called 4 times >> you stil need to set each of those 4 items even without the wrappers >> correct? though since all the wrappers do is call >> set_optical_parameters they should probably be removed anyways. >> >> 2009/3/25 Gray Water <[email protected]>: >> >> >> Your patch was not commited because it locked my computer up several >> times. >> >> Luckily I hope to have found the cause: >> 1. set_optical_parameters() is very performance hungry - which is ok >> љљ as long as it is called only once. >> 2. MPlayer always resets the video device ("just to make sure"). >> 3. Our reset function calls set_optical_parameters() 4 times >> љљ through wrapper functions: >> љљ - contrast >> љљ - brightness >> љљ - hue >> љљ - saturation >> 4. Together with the isoc_init in the usb subsystem, the buffer system >> љљ initializing itself and mplayer loading libv4l in userspace my computer >> љљ can't cope and locks up. >> >> љљ Hopefully removing the wrappers as I suggested before will fix this. >> >> љљ GWater >> >> >> 2009/3/25 Boris Borisov <[email protected]> >> >> >> Brian >> You are not push the patch for control of hie and saturation. >> Brian Johnson wrote: >> >> Pushed >> >> On Tue, Mar 24, 2009 at 12:38 PM, Josua Grawitter >> <[email protected]> >> wrote: >> >> >> Am Dienstag 24 MДrz 2009 17:32:28 schrieb Brian Johnson: >> >> >> Ok If noone has any issues with these patches i'm going to push them >> when i get home later this this evening. >> >> On Mon, Mar 23, 2009 at 2:46 PM, Pablo Castellano >> >> <[email protected]> wrote: >> >> >> Brian Johnson wrote: >> >> >> Alright here is a thread to post any patches to test this weekend. >> >> I've attached my wo patches i've been working on to this message >> 1. adds support for USB suspend/resume >> 2. exposes webcam button presses via the linux evdev input system >> >> >> Suspend/Resume support seems to work reasonably well on my own >> machine, with me being able to open up mplayer suspend the machine and >> when i resume mplayer is still delivering a valid video stream. >> >> My second patch is is a combination of the two patches related to >> webcam buttons in a previous post that i have combined into one as >> well as modified my thread function to support suspend/resume. This >> patch probably needs a bit of testing with different web cams that >> have buttons. It should work ok as it is now, however i would like >> some more information about which webcams are known to have buttons, >> if there are any that have more then one and which bits in the general >> purpose input registers(1005 and 1009) are set when a button is >> pressed. You can find out that information using debugfs. Testing the >> current button events cn be done using gizmod. >> >> # sudo gizmod -g >> >> Thsi will start gizmod in debug mode and you should see information >> about BTN_0 - BTN_7 show up when pressing your webcam buttons >> >> >> Nice job! This is the only thing I can say :) >> >> -- >> Regards, Pablo. >> >> >> Great. I hope to figure out my camera's problem with the saturation >> patches >> >> >> this evening and when they are in it's time for final testing and kernel >> submission. >> >> 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 -~----------~----~----~----~------~----~------~--~---
