Make osxmakeitoctave3.m compatibe with Octave-Forge's Octave-3.8.0 release.

Requires definition of different -rpath’es. We do so and drop support
for Octave 3.6.x.
Requires some replacement of … line continuation by \ continuation.
Move the “-W, -mmacosx-version-min=’10.6’” statements out and into the
mkoctfile of the octave installation used for building. For some
reason, 3.8.0’s mkoctfile can’t parse our -W — compiler option
statements anymore.
Hack octave-3.8.0’s mkoctfile to use gcc and g++ as compilers and
linkers, instead of the bundled gcc-mp-4.7 or such, which has trouble
with some Apple’isms in OSX headers, e.g., for some IOUSB includes as
needed by PsychHID.

-> All mex files for 64-Bit Octave 3.8.0 on OSX rebuilt and basic
tested.
-> End of support for Octave 3.6 and earlier on OSX.
Linux/TimeGlue: Make remapping of monotonic time to reftime more precise.

If PsychOSMonotonicToRefTime() has to take remapping action, make sure
- by use of a requery loop - that the mapping has an error bounded to
at most 20 microseconds.

This avoids very occasional spikes of up to 160 usecs observed on some
low end hardware. These spikes weren’t really problematic, but
confusing during debugging of high precision timestamping, so avoid
this confusion in the future.

-> Would be good to reevaluate if we can’t switch our reference
timebase from CLOCK_REALTIME to CLOCK_MONOTONIC for lower overhead and
even better precision. Most api’s we use would allow to do that now.
Update Nvidia GPU handling for NV-E0 and later.

NV-E0 “Kepler” and later cards need different registers to be read for
retrieving the VTOTAL and vblbias values needed for beam position
timestamping correction. So much is clear from Ben Suppnik’s nouveau
patches. Therefore add new handling code for the NV-E0+ case. What
isn’t clear yet is if the register base addresses in Ben’s patch are
correct - due to lack of testing hardware.

Another open question is if NV-D0 GPU’s belong into the C0 or the E0
category? For now we assign them to C0, in accordance with the nouveau
Wiki’s Code->Names mapping page at
http://nouveau.freedesktop.org/wiki/CodeNames/
However, this contradicts the nouveau-kms patches which treat D0 the
same as E0 and F0? Which one is right?

-> Code applies to Linux and OSX.

-> Screen for 64-Bit Octave 3.8 on OSX rebuilt and tested on NV-A0
type, NV-50 class Nvidia GeForce GT 330M.

-> Testing of NV-50 code path shows surprisingly that the VACTIVE reg
(according to nouveau ams) contains the same vtotal values as the
VTOTAL register according to PTB. The SYNC_START_TO_BLANK_END reg of
PTB contains the same value as VBLANKE from nouveau-kms, which is
expected and reassuring. This means that the nv-d0 code of Ben is
probably correct and applicable for us as well.
Mex files: Bump version number from 3.0.11 to 3.0.12

To apply at next recompile for upcoming 3.0.12 release.
Screen for 64-Bit Octave on Linux rebuilt for testing.
Screen for 32-bit Octave on Linux rebuilt for testing.
Screen/dc1394: Add support for execution of 2D marker tracker plugin.

Add two new subfunctions to Screen('SetVideoCaptureParameter') for
the libdc1394 firewire video capture engine on Linux and OSX:

'LoadMarkerTrackingPlugin=' allows to specify a marker tracker plugin,
which gets loaded and linked into the Screen() function, and sub-
sequently executed by the video frame processing thread during
Firewire video capture operations. The plugin must be implemented
by a shared library. We leave the supported API/ABI unspecified
for now, as this is a highly experimental feature which will change
without notice or any backwards compatibility. It is meant for
prototyping some new interesting future applications.

'SendCommandToMarkerTrackingPlugin=' allows to send ASCII strings
with commands to the loaded tracker plugin, to configure its
operation.

-> Screen mex file for 64-Bit Octave on Linux rebuilt and tested.
Ask(): Make compatible with Linux by default.

On Linux, GetChar() usually returns ascii code 13 instead of
10 for a 'RETURN' key press, so also check for code 13 for
terminating keyboard input.
Screen/dc1394: Add new flag for latency reduction in multi-cam capture.

A new optional 'SyncMode' flag 32 (kPsychNoLockStepSync) allows to
minimize processing latency in the video capture/processing/recording
threads of the dc1394 engine. Setting the flag will cause the slave
camera threads to no longer wait for the master camera thread to
reach a framecount, ie., all threads will work in parallel and the
slaves won't wait for the master to finish processing a framecount
before starting their processing themselves. This avoids adding a
delay of the duration of processing on the master thread.

-> Helpful for low-latency video capture / video processing on
   multi-cam setups.

-> Downside: While cams still start and execute capture in sync,
   they may stop asynchronously, ie., some cameras may capture or
   record one or multiple more frames than the master thread due
   to variability in scheduling on the os and the firewire bus.
   This is usually not a problem for capture and tracking apps,
   but could be a slight hassle for video recording apps.

-> Screen for 64-Bit Octave on Linux rebuilt and tested.
VideoPluginCaptureDemo: Demonstrate use of dc1394 video processing plugins.

A backup commit, useless without the corresponding plugin. Just
to demonstrate basic use of the plugin API for the dc1394 video
capture engine.
VideoDVCamCaptureDemo: Performance tuning for MS-Windows.

Testing on MS-Windows (Windows-7) with both 32-Bit and 64-Bit Matlab
R2010b and a Sony DV-PAL camera shows that the code as shipped in the
30-Dec-2013 beta works. However, use of video/x-dv caps is not
necessary, and performance is suboptimal with the dvdec decoder. Remove
superfluous caps and switch to ffdec_dvvideo, which shows good
performance - capture at 25 fps, as expected.

Testing with theoraenc video codec, but *no sound* shows that pure
video recording with theoraenc works well at full performance and
resolution as well.

-> All good in Windows-land at lest for PAL-DV firewire cameras, no
testing with NTSC-DV possible.
-> Btw. while dshowvideosrc works well, ksvideosrc doesn’t work at all
with either DV or DC1394 cameras. We should make sure to prefer
dshowvideosrc over ksvideosrc, as it seems to be much more robust with
many cameras.
VideoDVCamCaptureDemo: Remove audio hack on Linux.

A much better way to get DV recording on Linux working is
to not use an ancient GStreamer installation ;-)
Now it also works without the audio-enable hack on Ubuntu 12.10.
Screen for 32-Bit Octave on Linux rebuilt for testing.
PsychCamSettings(): Add support for AVT Marlin F033 series.
Maintain different set of PsychtoolboxKernelDriver's for pre 10.9 vs. 10.9 and later.

Rename PsychtoolboxKernelDriver32Bit to
PsychtoolboxKernelDriver32BitLegacy to signal it is no longer
maintained status. Add back September 2013 64 bit PTKD as
PsychtoolboxKernelDriver64BitLegacy, as apparently our latest December
2013 driver is no longer compatible with OSX 10.8 and earlier. This one
is now also unmaintaned.

The PsychtoolboxKernelDriver64Bit.kext.zip is the only version still
maintained and it works on the 64-Bit kernels of OSX 10.9 and
(hopefully) later.
PsychImaging('EnableNative10BitFramebuffer'): Execute LoadIdentityClut() during setup.

This is not needed for identity LUT loading, as the hardware LUT’s are
bypassed in 10 npc mode anyway, but as a side-effect it also disables
output dithering on all outputs. This was not necessary in the good’ol
days of analog VGA CRT monitors, but now that 10 bit digital flat
panels are a reality, we do need to explicitly disable output dithering.
-> Reported by Nicolas Cottaris when testing Radeon HD 4870 with a Sony
PVM-2541A 10 bit panel.
-> This fixes ops on that panel and gives well working 10 bit output,
as tested on OSX 10.8.5 with its
PsychtoolboxKernelDriver64BitLegacy.kext.
WhiteIndex(): Only allow calling on Onscreen windows and screenId's.

Clarify this is not for offscreen windows/textures in help text and
error-out if somebody tries to call on non-onscreen windows or screens.
PsychKinect: Update docu and help text for "Microsoft Kinect for Windows"

Turns out libfreenect version 0.2 (for Linux) and 0.3 (for OSX) and
later do now support the Kinect for Windows boxes, not only the
original XBOX-360 kinect. Explain this to user.
Our MS-Windows driver is still XBOX-360 Kinect only, as it doesn’t use
libfreenect as backend, but a special MS-Windows version of a Kinect
backend which is only api compatible to libfreenect, but not abi
compatible. That backend doesn’t do “Kinect for Windows” yet.
Screen: Disable digital output dithering on AMD gpu's if native 10 bit frame buffer is enabled.

Disable dithering inside Screen()’s 10 bit setup code, remove it from
PsychImaging, so we simplify this a bit for the end user.
-> Screen for 64-Bit Matlab on OSX rebuilt for testing.
Screen/PsychtoolboxKernelDriver: Move NV-D0 gpu's into the NV-E0 category.

Treat D0 chips as E0 family chips for all display engine handling,
e.g., beam position queries.
This is consistent with nouveau-kms, which treats d0, e0 and f0+ as one
family wrt. to display engine properties. It contradicts what the
nouveu wiki says (about e0, f0+ being a new generation), but we trust
the code a bit more and make it consistent with nouveau. I don’t have
access to any d0 class hardware, so let’s just hope it does the right
thing.
-> Linux and OSX source code updated. No recompile yet.