Ok I've pushed both the long standing hue/saturation patch by Boris and Stefan's slight optimization to the software AE routine.
On Sat, Mar 28, 2009 at 12:05 PM, Stefan Krastanov <[email protected]> wrote: > Brian, > If the max/min check is done before dark/bright check one may fall in the > following conditions: > > 1.The luminosity is very hight (the lamp is in front of the camera) so the > exposure gets under 0x10 and we are ok for the moment > 2.The lamp is turned off - we need to raise the exposure but the exposure is > under 0x10 so the function returns before even checking if there is need to > change the exposure (the dark/bright check) > > Maybe I missed something and I'm sure that there is always a better method, > but for the moment I'm not seeing it. > > If I can help with something, or maybe run some more intensive tests, just > tell me. > > Should I add likely/unlikely tags to the if-statements? > > 2009/3/28 Brian Johnson <[email protected]> >> >> this patch looks ok though is there any reason not to just the maximal >> and minimal values before even checking if the images is too dark or >> too bright? >> >> Also this function gets called everytime the dqbuf ioctl is called to >> dequeue a video frame. >> >> On Sat, Mar 28, 2009 at 10:02 AM, Stefan Krastanov >> <[email protected]> wrote: >> > Here is the patch. The difference is that now soft-AE checks if we are >> > already at maximal/minimal exposure and exits if that's the case. There >> > are >> > some hardcoded values for what I call maximal/minimal exposure that are >> > working for me, and I hope they will not cause any problem, but I'll be >> > grateful if someone from the developers inspect the changes as they are >> > only >> > 10 lines of code. >> > >> > And I must note - soft-AE is still called - it's just exiting faster if >> > there is nothing useful to do - as I have no idea who is the caller I >> > may be >> > missing some potential speedup. >> > >> > Regards >> > Stefan >> > >> > 2009/3/28 Stefan Krastanov <[email protected]> >> >> >> >> I made some test on the soft-AE and it seems it may be part of the >> >> problem. >> >> >> >> I edited it so it writes to dmesg every time it changes the exposure >> >> level. Here are the results: >> >> >> >> for origin/HEAD: >> >> normal use - 15 changes for 20 seconds >> >> a bit more light than normal - 8 changes for 20 seconds >> >> extreme luminosity(a lamp in front of the cam) - 137 changes for 20 >> >> seconds >> >> >> >> with hue_sat.patch: >> >> normal use - 11 times for 20 seconds >> >> a bit more light than normal - 11 changes for 20 seconds >> >> extreme luminosity(a lamp in front of the cam) - 450 changes for 20 >> >> seconds >> >> >> >> Although the test are not quite scientific I believe it's clear that >> >> soft-AE is not working well with extreme luminosities(and probably in >> >> darkness we'll have the same problem) and that the hue-sat.patch is >> >> making >> >> it a bit worser. >> >> >> >> I hour or two I'll send a patch to address the problem, sorry for the >> >> inconvinience that I created. >> >> >> >> There was another problem with the hue-sat.patch - two times my laptop >> >> hanged when inserting the usb cable from the camera and dmesg >> >> complained >> >> about not being able to do something with register 1005 or something >> >> like >> >> that. Exuse me for the inexact report but I needed to reboot and was >> >> unable >> >> to save the dmesg nor to reproduce the problem >> >> >> >> Best regards >> >> Stefan >> >> >> >> 2009/3/28 GWater <[email protected]> >> >>> >> >>> I just tested a bit more and it seems the performance problem is >> >>> already in origin/masterHEAD~2 (http://repo.or.cz/w/microdia.git? >> >>> a=commitdiff;h=9c5f82199c365e847906919af0f3b985fbc1696a). Although >> >>> there was no lockup there was one very interesting thing: >> >>> Framerate drops visibly when the camera input gets brighter. When the >> >>> sensor adapts (via AEC or AGC) the framarate stabilizes. If that >> >>> doesn't work the framerate stays low and mplayer gets upset. >> >>> The only few reasons for a lockup under these circumstances are: The >> >>> USB-subsystem deosn't like empty isochronous pipes. Or soft-AE has >> >>> some side effect when it gets a very bright frame (BTW I don't use it >> >>> - this is just the avgy calculation). OR fglrx is crappy (whoo - we >> >>> didn't know that!). >> >>> >> >>> Anyway I propose the following: >> >>> We investigate this issue further but in the meantime the saturation >> >>> patch goes into the repo. It maybe put the cream on top of some >> >>> performance problem but the real cause is most likely somewhere else. >> >>> >> >>> The question is: >> >>> To be or not to submit for 2.6.30 now? Maybe staging? >> >>> >> >>> GWater >> >>> >> >>> On 28 Mrz., 11:14, GWater <[email protected]> wrote: >> >>> > I tested and I finally got something to show you: >> >>> > >> >>> > $ dmesg >> >>> > 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 >> >>> > input: SN9C20X Webcam as /devices/pci0000:00/0000:00:02.1/usb1/1-4/ >> >>> > input/ >> >>> > input6 >> >>> > sn9c20x: Hue Value: >> >>> > 180 >> >>> > sn9c20x: Hue vsettings.hue: >> >>> > 0 >> >>> > sn9c20x: Hue Value: >> >>> > 180 >> >>> > sn9c20x: Hue vsettings.hue: >> >>> > 0 >> >>> > 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: >> >>> > 0 >> >>> > sn9c20x: Hue Value: >> >>> > 180 >> >>> > sn9c20x: Hue vsettings.hue: >> >>> > 0 >> >>> > BUG: soft lockup - CPU#0 stuck for 62s! [kondemand/ >> >>> > 0:1568] >> >>> > Modules linked in: sn9c20x fuse it87 hwmon_vid ipv6 >> >>> > nf_conntrack_netbios_ns cpufreq_ondemand powernow_k8 freq_table >> >>> > dm_multipath uinput ppdev radio_gemtek_pci snd_seq_dummy >> >>> > snd_hda_intel >> >>> > snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss >> >>> > snd_mixer_oss snd_pcm snd_timer snd_page_alloc snd_hwdep k8temp >> >>> > radio_maxiradio snd hwmon firewire_ohci compat_ioctl32 firewire_core >> >>> > videodev fglrx(P) pcspkr crc_itu_t pata_amd forcedeth v4l1_compat >> >>> > soundcore parport_pc parport i2c_nforce2 i2c_core ata_generic >> >>> > pata_acpi sata_nv [last unloaded: >> >>> > scsi_wait_scan] >> >>> > CPU >> >>> > 0: >> >>> > Modules linked in: sn9c20x fuse it87 hwmon_vid ipv6 >> >>> > nf_conntrack_netbios_ns cpufreq_ondemand powernow_k8 freq_table >> >>> > dm_multipath uinput ppdev radio_gemtek_pci snd_seq_dummy >> >>> > snd_hda_intel >> >>> > snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss >> >>> > snd_mixer_oss snd_pcm snd_timer snd_page_alloc snd_hwdep k8temp >> >>> > radio_maxiradio snd hwmon firewire_ohci compat_ioctl32 firewire_core >> >>> > videodev fglrx(P) pcspkr crc_itu_t pata_amd forcedeth v4l1_compat >> >>> > soundcore parport_pc parport i2c_nforce2 i2c_core ata_generic >> >>> > pata_acpi sata_nv [last unloaded: >> >>> > scsi_wait_scan] >> >>> > Pid: 1568, comm: kondemand/0 Tainted: P >> >>> > 2.6.27.19-170.2.35.fc10.x86_64 >> >>> > #1 >> >>> > RIP: 0010:[<ffffffff8123c5d7>] [<ffffffff8123c5d7>] usb_hcd_irq >> >>> > +0xa1/0xb3 >> >>> > RSP: 0018:ffffffff8170ec98 EFLAGS: >> >>> > 00000292 >> >>> > RAX: ffff88003d13b920 RBX: ffffffff8170ecb8 RCX: >> >>> > 00000000000006d0 >> >>> > RDX: 00000000ffffffff RSI: 0000000000000000 RDI: >> >>> > 0000000000000292 >> >>> > RBP: ffffffff8170ec10 R08: ffff88001a9f2800 R09: >> >>> > ffff8800178666a0 >> >>> > R10: 0000000014c88000 R11: ffff880017867000 R12: >> >>> > ffffffff81011408 >> >>> > R13: ffffffff8170ec10 R14: 0000000000000001 R15: >> >>> > ffff88003d13b800 >> >>> > FS: 00007f062e769950(0000) GS:ffffffff81717000(0000) knlGS: >> >>> > 00000000f7f2b710 >> >>> > CS: 0010 DS: 0018 ES: 0018 CR0: >> >>> > 000000008005003b >> >>> > CR2: 00007f6a96197000 CR3: 000000001b8cc000 CR4: >> >>> > 00000000000006e0 >> >>> > DR0: 0000000000000000 DR1: 0000000000000000 DR2: >> >>> > 0000000000000000 >> >>> > DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: >> >>> > 0000000000000400 >> >>> > >> >>> > Call Trace: >> >>> > <IRQ> [<ffffffff81082b1f>] ? handle_IRQ_event+0x33/0x6f >> >>> > [<ffffffff81083f12>] ? handle_fasteoi_irq+0xa5/0xeb >> >>> > [<ffffffff810130ce>] ? do_IRQ+0xf7/0x169 >> >>> > [<ffffffff81010963>] ? ret_from_intr+0x0/0x2e >> >>> > [<ffffffff81333b70>] ? _spin_unlock_irqrestore+0x33/0x3e >> >>> > [<ffffffff8103a6bf>] ? try_to_wake_up+0x271/0x283 >> >>> > [<ffffffff81010a37>] ? restore_args+0x0/0x30 >> >>> > [<ffffffff8104b388>] ? process_timeout+0x0/0xb >> >>> > [<ffffffff8103a6fd>] ? wake_up_process+0x10/0x12 >> >>> > [<ffffffff8104b391>] ? process_timeout+0x9/0xb >> >>> > [<ffffffff8104b0c6>] ? run_timer_softirq+0x19c/0x222 >> >>> > [<ffffffffa004830f>] ? nv_nic_irq_optimized+0xbd/0x277 [forcedeth] >> >>> > [<ffffffff81046c82>] ? __do_softirq+0x7e/0x10c >> >>> > [<ffffffff81011bfc>] ? call_softirq+0x1c/0x28 >> >>> > [<ffffffff81012e02>] ? do_softirq+0x4d/0xb0 >> >>> > [<ffffffff81046857>] ? irq_exit+0x4e/0x9d >> >>> > [<ffffffff8101311e>] ? do_IRQ+0x147/0x169 >> >>> > [<ffffffff81010963>] ? ret_from_intr+0x0/0x2e >> >>> > <EOI> [<ffffffff81016fc3>] ? native_read_tsc+0xc/0x22 >> >>> > [<ffffffff8116df60>] ? delay_tsc+0x26/0x58 >> >>> > [<ffffffff8116dff6>] ? __const_udelay+0x47/0x49 >> >>> > [<ffffffff8116e008>] ? __udelay+0x10/0x12 >> >>> > [<ffffffffa03f65df>] ? decrease_vid_code_by_step+0x33/0x3b >> >>> > [powernow_k8] >> >>> > [<ffffffffa03f6b61>] ? powernowk8_target+0x47d/0x8b5 [powernow_k8] >> >>> > [<ffffffff812857c3>] ? __cpufreq_driver_target+0x64/0x74 >> >>> > [<ffffffffa03fe751>] ? do_dbs_timer+0x1cb/0x235 [cpufreq_ondemand] >> >>> > [<ffffffffa03fe586>] ? do_dbs_timer+0x0/0x235 [cpufreq_ondemand] >> >>> > [<ffffffff81051c85>] ? run_workqueue+0xa3/0x146 >> >>> > [<ffffffff81051e1d>] ? worker_thread+0xf5/0x109 >> >>> > [<ffffffff8105553d>] ? autoremove_wake_function+0x0/0x38 >> >>> > [<ffffffff81051d28>] ? worker_thread+0x0/0x109 >> >>> > [<ffffffff810551f7>] ? kthread+0x49/0x76 >> >>> > [<ffffffff81011719>] ? child_rip+0xa/0x11 >> >>> > [<ffffffff81010a37>] ? restore_args+0x0/0x30 >> >>> > [<ffffffff810551ae>] ? kthread+0x0/0x76 >> >>> > [<ffffffff8101170f>] ? child_rip+0x0/0x11 >> >>> > >> >>> > hda-intel: IRQ timing workaround is activated for card #0. Suggest a >> >>> > bigger bdl_pos_adj. >> >>> > sn9c20x: [E] Empty buffer queue. >> >>> > sn9c20x: Hue Value: 180 >> >>> > sn9c20x: Hue vsettings.hue: 0 >> >>> > sn9c20x: Hue Value: 180 >> >>> > sn9c20x: Hue vsettings.hue: 0 >> >>> > >> >>> > (So, yes the system still locks up. This time I didn't even attempt >> >>> > to >> >>> > set saturation. I suspect mplayer is sending ioctl by itself.) >> >>> > >> >>> > GWater >> >>> > >> >>> > On 28 Mrz., 07:16, Boris Borisov <[email protected]> wrote: >> >>> > >> >>> > > 3 times OK from me >> >>> > >> >>> > > Brian Johnson wrote: >> >>> > > > ah was not aware that some chips didn't like setting spme of the >> >>> > > > color >> >>> > > > matrix independently. >> >>> > >> >>> > > > Updated version that adds the 21byte array into the >> >>> > > > sn9c20x_video >> >>> > > > struct so we can still sett the whole thing at once. >> >>> > >> >>> > > > 2009/3/27 Boris Borisov <[email protected]>: >> >>> > >> >>> > > >> Freezing on my camera the version of my bridge maybe is lowest. >> >>> > > >> No >> >>> > > >> way for >> >>> > > >> detection of version of bridge. All parameters (21 parameters >> >>> > > >> from >> >>> > > >> 10e1)must >> >>> > > >> be set at once for prevent of similar problem during iso >> >>> > > >> transfer >> >>> > > >> (I don't >> >>> > > >> know why perhaps some engine bug). That is the main problem. >> >>> > > >> On other one more new camera (same model 6270) is working. >> >>> > > >> I check with 3 different (as producer but same as model) >> >>> > > >> cameras 2 >> >>> > > >> is OK 1 >> >>> > > >> is NOK camera engine is freezing. >> >>> > >> >>> > > >> Brian Johnson wrote: >> >>> > >> >>> > > >> Here is a somewhat updated version of this patch that does >> >>> > > >> successfully break hue/sat, contrast and brightness up into >> >>> > > >> separate >> >>> > > >> functions and seems to work fine. Don't know if it will >> >>> > > >> actually >> >>> > > >> help >> >>> > > >> with the freezing when settings lower satuation that Joshua was >> >>> > > >> experiencing. It also fixes a few other minor issues like >> >>> > > >> accidentally >> >>> > > >> undoing a few previous commits, making RX, RY, etc static, and >> >>> > > >> adding >> >>> > > >> hue as a module param. >> >>> > >> >>> > > >> On Fri, Mar 27, 2009 at 1:50 PM, Brian Johnson >> >>> > > >> <[email protected]> >> >>> > > >> wrote: >> >>> > >> >>> > > >> I didn't look too much at why the global static array is not >> >>> > > >> working, >> >>> > > >> however you really do not want to use one here because it will >> >>> > > >> cause >> >>> > > >> problems the first time you try to have the driver handle two >> >>> > > >> different sn9c20x webcams. It would probably be better to add >> >>> > > >> it >> >>> > > >> to >> >>> > > >> maybe to the sn9c20x_video struct. Also not sure the array has >> >>> > > >> to >> >>> > > >> be >> >>> > > >> pre initialized either since given the first time you set >> >>> > > >> brightness,contrast,etc it will be filled out properly and we >> >>> > > >> will >> >>> > > >> do >> >>> > > >> this when the camera is initialized. >> >>> > >> >>> > > >> 2009/3/27 Boris Borisov <[email protected]>: >> >>> > >> >>> > > >> I do some investigation of function set_optical_parameters as I >> >>> > > >> transfer >> >>> > > >> execution of instruction into user space and disassemble the >> >>> > > >> program. >> >>> > > >> For reference I use cycle execution of i486 worst case (is >> >>> > > >> possible for >> >>> > > >> some instruction to not get the correct cycles but as >> >>> > > >> estimation >> >>> > > >> is good >> >>> > > >> start). >> >>> > > >> Possible optimization: >> >>> > > >> 1. Define __u8 optical_parameters[21] as global static - I try >> >>> > > >> but >> >>> > > >> always the values is not save on this global static array - >> >>> > > >> What I >> >>> > > >> do >> >>> > > >> wrong ??? Pleas for some idea about __u8 optical_parameters[21] >> >>> > > >> (see in >> >>> > > >> patch what i want to do with this array ) ??? For first time >> >>> > > >> global >> >>> > > >> initialization of array is not work for me ??? >> >>> > > >> If this array going into global space as static the functions >> >>> > > >> can >> >>> > > >> split >> >>> > > >> into small parts for Brightness, Contrast, HUE-Saturation >> >>> > >> >>> > > >> 2. Possible optimization of calculation multiplying and >> >>> > > >> dividing I >> >>> > > >> can >> >>> > > >> replace with logic operation and reanalyze execution time. >> >>> > >> >>> > > >> 3. As total execution calculation of RGB matrix parameters is >> >>> > > >> not >> >>> > > >> get >> >>> > > >> too much microprocessor time (near to sn9c20x_set_gamma - too >> >>> > > >> many >> >>> > > >> multiplication and dividing ). Maybe other often call code get >> >>> > > >> this time. >> >>> > >> >>> > > >> diff --git a/sn9c20x-bridge.c b/sn9c20x-bridge.c >> >>> > > >> index f5d77b8..b4c3212 100644 >> >>> > > >> --- a/sn9c20x-bridge.c >> >>> > > >> +++ b/sn9c20x-bridge.c >> >>> > > >> @@ -30,8 +30,312 @@ >> >>> > > >> #include "sn9c20x.h" >> >>> > > >> #include "sn9c20x-bridge.h" >> >>> > >> >>> > > >> + >> >>> > > >> + >> >>> > > >> +/** >> >>> > > >> + * @var RX >> >>> > > >> + * Coordinate X aray for eliptic HSV corrections, >> >>> > > >> conditionaly >> >>> > > >> Red pixel >> >>> > > >> + */ >> >>> > > >> +const int RX[] = {41, 44, 46, 48, 50, 52, 54, 56, >> >>> > > >> + 58, 60, 62, 64, 66, 68, 70, 72, >> >>> > > >> + 74, 76, 78, 80, 81, 83, 85, 87, >> >>> > > >> + 88, 90, 92, 93, 95, 97, 98, 100, >> >>> > > >> + 101, 102, 104, 105, 107, 108, 109, 110, >> >>> > > >> + 112, 113, 114, 115, 116, 117, 118, 119, >> >>> > > >> + 120, 121, 122, 123, 123, 124, 125, 125, >> >>> > > >> + 126, 127, 127, 128, 128, 129, 129, 129, >> >>> > > >> + 130, 130, 130, 130, 131, 131, 131, 131, >> >>> > > >> + 131, 131, 131, 131, 130, 130, 130, 130, >> >>> > > >> + 129, 129, 129, 128, 128, 127, 127, 126, >> >>> > > >> + 125, 125, 124, 123, 122, 122, 121, 120, >> >>> > > >> + 119, 118, 117, 116, 115, 114, 112, 111, >> >>> > > >> + 110, 109, 107, 106, 105, 103, 102, 101, >> >>> > > >> + 99, 98, 96, 94, 93, 91, 90, 88, >> >>> > > >> + 86, 84, 83, 81, 79, 77, 75, 74, >> >>> > > >> + 72, 70, 68, 66, 64, 62, 60, 58, >> >>> > >> >>> > ... >> >>> > >> >>> > Erfahren Sie mehr » >> >>> >> >> >> > >> > >> > > >> > >> >> > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
