Brian Johnson schrieb:
Its been awhile since i've submitted any patches but here are several patches i've worked on over the last few months.The following is a brief overview of the changes made. - Fix bulk in bulk transport allowing it to work with jpeg format - Fix read() to support jpeg format - add module param to disable jpeg format - ensure format is set properly during initialization. - Since we only support sn9c20x chipset, renamed the driver. - changed v4l2 controls to have a max of 255. We only used the upper byte anyways. - Reworked sensor detection to specify sensor and slave address using the driver_info field in the device table - removed several functions that were never called anywhere - consolidated many of the wrapper functions called to set brightness,gain,exposure,etc - simplified formats to only use the bridge based formats. This means all sensors should be set to bayer during init, and we won't support stuff like yuv or various rgb formats that some sensors support. I don't think this is a problem with the use of v4l myself and tends to be what many of the kerenl drivers seem to do. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
This took a while to go through - you should post more often ;) .Seriously - some of my patches are obsolete now (which is in most cases a Good Thing) and I'd rather spend my time productively.
Anyway - great stuff. 0001: - reduces code, no loss, push it! 0002: - I know nothing about that stuff (and I don't use it) 0003:- great idea - I always figured we need to be able to disable it via libv4l but your solution is much more elegant (and simple).
0004: - Hey - I already tried that last summer! Why the sudden change of mind? Anyway - I support it. 0005:- I see this patch would simplify some things however I'm not sure I like the v4l cids to be mixed in there
0006:- I don't get your argumentation - why not put the max to 0xffff and allow a more exact setting. I know that most sensors (especially ov sensors) usually only offer 8-bit contrls but there are quite some exceptions. The integer type is necessary anyway (to be v4l2 compliant).
0007: - makes sense 0008: - no objections 0009:- ok, but maybe a "bandwidth" parameter will make them interesting in the future (AMcap has a similar setting)
0010:I agree (my sensor only offers bayer ;) ), however libv4l inclusion of the old decoders will become even more important because of this. Who's on it?
0011: no objections 0012: no objections 0013:- the last break statement before default is missing in the big switch (maybe not necessary?)
- else ok with me Looks like need to rebase some stuff ;) . GWater
signature.asc
Description: OpenPGP digital signature
