Screen/Linux: Massive comment/white-space/indentation cleanup.

Clean PsychScreenGlue/WindowGlue/WindowGlueWaffle[.h/.c] from
the mess of indentation errors and white-space disasters to
make those files more readable/manageable.

-> No real functional changes.
-> Screen for 64-Bit Octave on Linux test rebuilt.
Screen/Linux: Always override-redirect fullscreen windows on KDE multi-display.

As i learned from Martin Graesslin, KWin's maintainer at XDC 2014, KWin deliberately
doesn't unredirect fullscreen windows by default on Intel gpus, to work around bugs
in some versions of the Intel-ddx, that's why the Intel trouble. Therefore we must use
new-style for KDE to unredirect fullscreen windows to enforce compositor disable via
our XAtoms. However, this doesn't work for multi-display spanning windows due to what
i think is a KWin bug. On a dual-display setup, the right half of the window on the
2nd display gets cut off - the desktop is showing instead. No hack in the code or any
KWin rule i tried could prevent this cutoff, although the window itself is reported to
PTB as spanning both desktops - that's why this is probably not intentional KWin behaviour,
but a bug. To work around this we enforce old-style setup again on KWin + Intel + fullscreen
if there are at least two active video outputs connected to our target x-screen, aka
we are on a multi-display setup. This means the user has to manually disable desktop
composition if dual/multi-display stimulation on a Intel gpu under KDE/KWin is needed
with good presentation timing, as the manual "user says so" override is the only method
that worked.

-> Screen for 64-Bit Octave on Linux rebuilt and tested under KDE+Intel gpu, single
   and multi-display.

-> Single display is fully automatic as in the past.
-> Dual display needs manual compositor disable via control panel settings
   or SHIFT+ALT+F12 toggle by user.
-> Other gpu's than Intel are unaffected and KWin's unredirection of fullscreen
   windows works.
Screen/Linux: Be more lenient in detecting INTEL_swap_events.

Turns out that at least under nouveau-ddx with its glamor backend
enabled under DRI3/Present, the INTEL_swap_events extension is
fully supported and functional, but doesn't get advertised under
either the glXQueryExtensions() string, nor the server string. It
is only present in the client string. If this is spec conformant
or an omission on nouveau's side is unclear.

Our old matching code wouldn't enable use of this useful extension
under nouveau+glamor+dri3/present for this reason. Change the code
so it does. Now we try enabling the extension if it is advertised
in any of the GLX extension strings. Our code can easily handle
failure to enable the extension for real with no downsides, so this
should be all good.

-> Screen mex for 64-Bit Octave on Linux rebuilt and successfully
   tested under nouveau-ddx with dri3/present + glamor acceleration.
Fixed buglet where SaveCalFile could crash if passed filename was short.

Signed-off-by: David Brainard <brainard@psych.upenn.edu>
Add xorg.conf_SeparateScreensIntel as a sample xorg.conf for Dual-X-Screen.
Screen/GStreamer: Whitespace/Indentation cleanup for video capture.

Prep work for real changes.

-> Screen for 64-Bit Octave on Linux rebuilt.
Screen/GStreamer: Improve diagnostics for videocapture - print more info.

Not very useful for practical purpose though. Anyway, the work is
done so keep it in case it is ever needed.

-> Screen for 64-Bit Octave rebuilt and tested.
Fix way that full file path is computed to use fullfile.  This is more robust.

Signed-off-by: David Brainard <brainard@psych.upenn.edu>
Screen/GStreamer: Fix memory leaks when video capturing to memory.

If video is "recorded" to memory instead of immediately
dequeuing, processing and discarding frames, e.g., as in
VideoOfflineCaptureDemo, then severe memory leaks can happen.

This is partially our fault, and this commit fixes the found
leak inducers.

-> Screen for 64-Bit Octave on Linux rebuilt and tested.

However, for certain use patterns, GStreamers - or more
accurately GLib's - default memory slice allocator seems
to misbehave and cause large leakage of memory anyway. It
eventually frees memory, but only at certain trigger-points,
which depending on the machines memory configuration may be
too little, too late.

Testing with the environment variable setting...

export G_SLICE=always-malloc

... can switch to a more simple malloc() memory allocator
which frees "freed" memory immediately via the OS malloc
implementation, instead of caching "freed" memory chunks
in a SLAB allocator or per thread magazine allocator.

While this has a performance penalty, it seems to reliably
prevent memory leaks.

-> This is mostly only needed for "offline capture" into
memory, not for regular live capture->process->display->discard
operation.
VideoOfflineCaptureDemo.m: White-space / indentation cleanup.
Screen/GStreamer: Handle video sources with range of valid width x height.

Some framegrabbers return width and height of valid capture resolutions
not as fixed width x height pairs (one per cap), but for each cap as a
range of valid values, e.g., analog framegrabbers for connecting fMRI
compatible analog cameras. Modify matching logic to deal with it.

The whole auto-detection of suitable resolutions and framerates is
still a fragile thing on different cameras, as many cameras apparently
lie about their truly supported caps, or fail to mention restrictions
and caveats to the capture framework. A little sampling:

- The 2010 MBP iSight automagically works.

- The analog -> digital USB framegrabber thingy automagically works.

- The Logitech Cxxx USB webcam detects correct framerate but auto-selects
  a too high default resolution, which it then can't handle, so manual
  selection of a lower override resolution is required.

- The Sony PlayStation Eye 3 camera selects too high framerates - and hangs -
  if the 'realmax' value for fps auto-detection is used. It also hangs whenever
  no manual resolution is specified, although it auto-detects the correct
  resolution. The latter failure due to taking a different setup code path,
  which sets different basic colorcaps in auto-detect vs. manual override.
  Also it lies about what max fps it can handle at specific resolutions, so
  one has to find out by trial and error which combos of resolution and fps
  work. E.g., 320x240 works at up to 125 fps. 640x480 only works up to 30 fps,
  although the camera claims it can do 60 fps - and then malfunctions if one
  tries. Probably the 60 fps at 640x480 mode only works for special color
  caps settings which the cam fails to mention properly to the capture engine.

-> Sometimes there's just no winning. Reliable videocapture without manual
   parameter tweaking just seems to be against some law of nature.

-> Screen for 64-Bit Octave on Linux rebuilt and tested with above cams with
   above results.
Screen: Add timestamping fallback to DC1394 video capture engine.

libdc1394, as of December 2014, doesn't support timestamping for
captured video from USB-3 IIDC cameras, only from Firewire cameras.
Timestamps from USB-3 are therefore invalid/unuseable.

Add a fallback: If video capture/recording is done on the parallel
background capture thread, instead of synchronously on the main
thread, simple query current "GetSecs" time at time of frame
reception by the capture thread. As the capture thread uses
periodic polling for new frames, this has a minimum timestamp noise
and granularity of the polling interval + random scheduling jitter +
underlying USB-3 jitter/delays. In 'lowlatency' / 'dropframes' mode,
the poll interval is roughly 1 msec, in normal mode it is roughly
4 msecs. Anyway, some kind of rough timestamps might be better than
none at all.

-> Screen for 64-Bit Octave on Linux rebuilt, test pending.
Screen: Improve timestamping fallback for DC1394 video capture engine.

libdc1394 doesn't zero-init the timestamp field properly, so
timestamps on the USB backend arent't nicely zeroed to signal
lack of support, but contain random trash numbers - Hard to
detect reliably if backend supports timestamps or not.

To allow running on existing, non-fixed libdc1394 versions,
use a different approach:

1. We detect if camera is Firewire or USB. Iff Firewire, use
   precise timestamps. Iff USB, use fallback.

2. Detection is a hack in itself: libdc doesn't expose the
   info about its version number or the backend in use via
   public stable api afaics - unless i overlooked it somehow.
   Therefore we check if dc1394_read_cycle_timer() is supported.
   On Firewire, this is supported, on USB it is absent atm., so
   use it as Firewire vs. USB backend indicator.

-> Screen for 64-Bit Octave on Linux rebuilt and tested against
   a IIDC Firewire cam and a IIDC USB-3 Vision cam. Works.
MergeCell did not handle empty inputs as it should (ignoring/early exit)
Merge pull request #223 from dcnieho/MergeCell_patch

MergeCell did not handle empty inputs as it should (ignoring/early exit)
Screen: Add NVidia Maxwell support for beamposition timestamping.

Our detection code didn't handle chip id's > 0xff, but Maxwell
has id's of >= 0x110, which wrapped around to 0x10 for NV-10 class
prehistoric hardware, causing beampos query failure.

Update code for at least the 0x100 range to handle Maxwell's
display engine. Also adjut our d0 vs. e0 family mapping properly,
something we omitted in the past. This doesn't cause a functional
change but makes the logic easier to understand - less head scratching!

This sync us up with nouveau's Linux 3.18 behaviour.

-> Screen for 64-Bit Octave on Linux rebuilt, but not tested due
   to lack of test hardware.

-> Rebuild for Screen on Matlab and on OSX pending.
Merge branch 'master' of https://github.com/kleinerm/Psychtoolbox-3

Conflicts:
	Psychtoolbox/PsychBasic/Octave3LinuxFiles64/Screen.mex
Screen for 64-Bit Octave on Linux rebuilt to resolve merge conflict.
Screen for 64-Bit Matlab on Linux rebuilt with Nvidia Maxwell support.

-> Untested.
Screen for 64-Bit Octave/Matlab on OS X rebuilt for Nvidia Maxwell support.

-> Untested.