Recent changes to patches

tas5110d sensor (for 0c45:6007)

Thu, 01 Aug 2013 09:00:36 -0000

Here is an experimental patch for the tas5110d sensor, based on these commits to gspca:

Note that the setbrightness() function may have changed to setsensorgain() and/or setgain().

Also refer to this commit:

V4L/DVB (8835): gspca: Same pixfmt as the sn9c102 driver and raw Bayer added in sonixb.

The patch applies to revision 1.9 of the file sonix.h, using the CVS repository as of 2013-08-01.

The brightness slider has *some* effect, and the issue of the image being mirrored is fixed. Testing with a Genius VideoCAM Eye (0c45:6007).

So far this is just a quick test. Need to put in separate cases for the tas5110c and d, and create subclass(es) for cameras that use the d.

OV538Driver VGA,QVGA frame/buffer changes

hdc — Sat, 27 Nov 2010 04:49:58 -0000

Attached tar file includes full and patch versions (against cvs as of Nov 25, 2010) of files:

cameras/OV534Driver.h
cameras/OV534Driver.m

NOTE 1 this update REPLACES all of my previous patches; hxr has updated cvs so you DO NOT need my copies of the fixes for files:

driver_code/MyCameraCentral.m
utilities/FrameCounter.m
utilities/Histogram.m

NOTE 2 - this is update is just a very minor cleanup of the comments and some minor code cleanup and does not change any of
the functionality of my earlier OV538 patches. I'm submitting this patch primarily to confirm that this is a clean patch against the
current cvs (as of Nov 25, 2010)

NOTE 3 - I'm running OS X 10.6.5 and using Xcode 3.2.5 (latest) - I did not need to make any other changes to compile either the
macam app or the component. I just updated OV534Driver.h and .m. See the earlier patch submissions I made for a couple of
minor notes on building under Leopard and Tiger and earlier versions of Xcode.

Summary - you can just take a current copy of cvs and apply the patches for OV534Driver.h/.m or replace those files w the full copies;
both the patches and the full copies are in the attached tar file.

Notes on the fixes are largely unchanged and as follows:

Primarily a small change to allow for per-resolution setting of the frame (hardware) and buffer (driver) sizes so that they match expected values.
- fixes the 2 missing pixel bug (bug ID 2991591)
- changes how QVGA/SIF buffers are handled so it is a true 320x240 frame and buffer size
- results in fewer short buffers (w side effect that fps calc is more accurate or at least matches vsync frequency...)

- added initial hardware control of sharpness (enabled sharpness slider) and a greyscale mode (enabled "B&W" checkbox in the settings panel of the app)

I should add that while the camera hardware seems to support frame rates above 60fps at VGA or QVGA/SIF, the macam app or component won't play or record beyond about 60fps (confirmed on an iMac i7 quad). Figured that if VGA @ 60fps works (it does) then QVGA @ 75fps would work too (1/3 the data rate?) but it still max's out at about 60 (tho the vsync signal in the camera hardware and the "receiving" fps displayed are at 75Hz and fps). So, assuming I'm just missing something obvious here...

Still need to do - and somewhat out of my depth yet on the last 2:

- clean up all setResolution values to match listed fps rate w actual set rate (this is esp. true of the SIF sets due to the change of the buffer size etc.)
- need to figure out how to debug the component properly in order to track down the -536870206 error when video and audio sources are set to PS3eye at the same time; QT7 draws at least one frame and then dies; component works fine if only one of the sources is set to the PS3eye
- need to still track down source of nextImageBuffer going south when macam app attempts to record to a file under 10.6; dies in yuv_to_rgb - r,g,b pointers are bad; it seems so simple...

(summary of comments in the OV538Driver implementation section of the code (about 1/2 way down in the file: OV534Driver.m))

// - modified startupGrabStream to include per-resolution setting of payload and frame sizes
// based on ideas from linux drivers (ov534.c) allowing QVGA/SIF mode to transfer matched
// (320x240) buffer instead of 2x that
//
// - modified frame size for VGA so that 2 "missing pixels" are included; this also required
// adjusting horizontal sensor start and sensor size (0x17 and 0x18 registers; compare what is
// still in initCamera for these vs. what's listed in startupGrabStream); these may need more
// tweaking - the +4 to 0x18 seems odd - some header not accounted for or something?
//
// - above changes (QVGA frame size and VGA missing pixel fixes) allowed setIsocFrameFunctions
// to be returned to:
//
// grabContext.chunkBufferLength = 2 * [self width] * [self height];
//
// buffer sizes are now consistently 614400 for VGA and 153600 for QVGA/SIF
//
// - modified decodeBufferProprietary to eliminate ptr += rawWidth * 2 now that frame matches buffer for QVGA/SIF
//
// - numerous tweaks to setResolution register combinations; NOTE FURTHER adjusting is now
// req'd after above-mentioned payload/frame size changes etc.
// - confirmed many combinations against hardware (e.g. VSYNC frequency) using oscilloscope
// - added comments on various register combinations tried and limits encountered through trial and error:
//
// sensor register 0x11 : lower 6 bits : 0x00 (fast) - 0x3f (slow) : it seems bits 7 and 8 must be 0 (as tested in macam 092)
// sensor register 0x0d : bits 7 and 8 : 0xc0 (fast) - 0x00 (slow) : other bits seem to be don't care
// register 0xe5 : lower 5 bits : 0x00 (fast) - 0x1f (slow) : other bits seem to be don't care
//
// 0x11 0x0d 0xe5
// ----------------
// 0x3f 0x00 0x1f slowest register combination - about 0.03fps or 1 frame every 25-30 seconds... (auto exposure adjustment takes many frames so waait for it)
// 0x00 0xc0 0x00 fastest register combination - probably too fast for hardware and/or USB

Update to use Garbage Collection

Madd the Sane — Mon, 04 Oct 2010 01:40:23 -0000

This patch allows macam to support Garbage-Collection. Please note that this is untested, so there still may be problems on Garbage-Collecting Apps.

French's DriverLocalizable.strings is in MacRoman

Madd the Sane — Mon, 20 Jul 2009 00:38:10 -0000

The French's DriverLocalizable.strings is encoded in Mac Roman, but the project file thinks it's UTF-16. This causes problems when Xcode tries to copy over the strings using the built-in command 'copystrings' which converts the strings file into the UTF-16 (or UTF-8, depending on the project settings) Character encoding.

Two identical cameras

Andrey Gruzdev — Sat, 07 Jun 2008 08:37:36 -0000

I have two identical cameras VF0400
The component gives different names for them such as
macam #1: Creative.....
macam #2: Creative.....

but then either I select first or second the image comes from only one camera
I have make patch for camera naming nameForID: in MyCameraCentral.m and now it works (with and without "macam #" addition in QTVideoDigitizer.m )

May be nameForID: modification can corrupt something else - hope not

VF0400 hardware features

Andrey Gruzdev — Fri, 06 Jun 2008 18:24:24 -0000

There are some camera capabilities used:
flip and mirror
rotation sensor (autoflip) with register monitor timer
brightness and contrast registers fixed
hub compatibility delays reduced

Creative Webcam NoteBook slow rate

Andrey Gruzdev — Wed, 04 Jun 2008 14:59:10 -0000

In 0.9.2 Creative Webcam NoteBook frame rate becomes very slow

- (void) startupCamera
{
[super startupCamera];
[self setCompression:2]; // 2 instead of 1 makes normal frame rate
}

in ZC030xDriver.m

Creative VF0400 Live! Cam Notebook Pro color bug

Andrey Gruzdev — Tue, 03 Jun 2008 11:35:07 -0000

method - (void) setResolution:(CameraResolution)r fps:(short)
corrupts sensor color settings

Russian localization

Andrey Gruzdev — Sat, 05 Apr 2008 15:18:31 -0000

Translation of messages, interface and help
May be needs correction

Q-Cam 330 VGA support

Andrey Gruzdev — Tue, 18 Mar 2008 15:37:18 -0000

Q-Cam 330 VGA: et61xx51 based
vid: 0x102c
pid: 0x6251
only 320x240 resolution reached