Ok I've been really busy recently but i have a few comments about the recent patches.
First i may have missed this but what is the reasoning behind statically assigning the sensors based on device? I don't really mind statically assigning the sensor perse, I just perfer determing the sensor using a single method and am unsure what was decided was wrong with simply probing for all sensor types. That being said if we would rather go with the dual approach, you should not be defining another array of webcams. We already have one in the form the device ID table in microdia-usb.c. Each member of that table has a 32bit driver_info field which can be used to store various information. Currently its storing just the bridge id in the upper 16 bits which we probably don't need to do since we are only supporting sn9c20x bridge. Anyways, that field should probably be used to store a sensor id. You could also make special sensor id called SENSOR_PROBE that if used will cause the driver to do probing. Ok second issue, why were all the format/resolutions condensed into a single microdia_default_fmts array, instead of remaining separate per sensor? This has some problems that i can see already. First our driver currently lies about what formats are supported. Since if you don't have have a set_yuv422 function defined for your sensor you don't really support that format yet our driver will say you do. Second and i think more problematic is that if you have multiple attached webcams they will all be using a reference to the same structure, which is a problem since you then procede to modifiy that shared reference based on what senspor was attached to the currently probed webcam. This will cause all sorts of confusion if your multiple webcams use different sensors. On more minor thing the sn9c20x_write_i2c_data function was modified to allow for an extra byte to be passed in, yet this does not seem to be used anywhere, Is this necessary for some yet unimplemented feature? I do really like the new software auto exposure for the omni vision sensors though it works just fine on my 624f. On Mon, Dec 1, 2008 at 3:25 AM, GWater <[EMAIL PROTECTED]> wrote: > Jon Arnold schrieb: >> >> I'm having trouble using Cheese and the gstreamer test window. For >> some reason, the resolution options in Cheese are all squares (ex. >> 512x512). The kern.log shows this: >> Nov 30 22:12:03 ubuntu kernel: [12768.080593] microdia: Iso frame 0 of >> USB has error -18 >> >> with numbers up to 9 for the Iso frame.... >> >> On Nov 30, 4:20 pm, GWater <[EMAIL PROTECTED]> wrote: >>> >>> Vasily Khoruzhick schrieb: >>> >>>> On 30 November 2008 22:58:26 GWater wrote: >>>>> >>>>> I did send you the modified patch, didn't I? >>>>> If you didn't get it - here it is again. >>>>> GWater >>>> >>>> No, you didn't :) >>>> Here's slightly modified version >>>> Vasily >>> >>> Works for me. >>> >>> GWater >>> >>> signature.asc >>> < 1KViewDownload >> >> >> > > The iso errors are ok if they stop eventually - it just needs sme time for > the system to adjust itself. > If they keep coming it's BAD. > > Is this resolution behaviour normal for cheese or did this just come with > the new driver version? > > Do you use libv4l or gstreamer to decode the JPEG? Is gstreamer really able > to decode that? > > 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 -~----------~----~----~----~------~----~------~--~---
