Screen/Linux: DRI3/Present bug workaround I - glXWaitForSbcOML()

As of Mesa 10.3.3, Mesa's DRI3/Present implementation of
glXWaitForSbcOML() is broken in that it doesn't treat the
targetSbc=0 special case properly. Instead of blocking until
all pending bufferswaps have completed, it just falls through
and returns whatever last (ust,msc,sbc) triplet comes along its
way. This caused various disastrous failures in PTB's swap
scheduling and timestamping.

Workaround this by:

1. Implementing PsychOSFlipWindowBuffers() as a call into
   PsychOSScheduleFlipWindowBuffers() with equivalent swap
   timing, by use of targetSBC=1, divisor=remainder=0. This
   way the windowRecords->swaptargetSBC gets updated with the
   expected SBC of swap completion.

2. Using that value in PsychOSGetSwapCompletionTimestamp() in
   the targetSBC=0 case, so glXWaitForSbcOML() gets called with
   a specific non-zero targetSBC and mostly does its job.

-> This should have no negative impact on performance or reliability/
   precision compared to the old implementation wrt. both DRI3/Present
   or good old DRI2, so we can keep this unconditionally enabled.

-> This fixes swap scheduling and swap timestamping when tested
   under XOrg 1.16.2 + mk-fixes with standard Mesa 10.3.0 under
   nouveau-ddx master on nv-50 with 'exa' backend on a Linux 3.17
   kernel with rendernodes enabled and thereby DRI3/Present in use,
   both for non-composited and composited setup, fullscreen, transparent
   and windowed. More tests (glamor, intel-ddx sna/uxa/glamor) pending.

-> There are more bugs in Mesa, which are currently worked around:
   Scheduling a glXSwapBuffersMscOML() swap with targetMSC=0 causes
   the swap to hang -- the request never reaches the server! Needs
   investigation, likely another Mesa bug.

-> Potential race between glXGetSyncValuesOML/glXWaitForMscOML() and
   glXWaitForSbcOML() under DRI3/Present: Mesa uses same ust,msc
   vars for all those functions, so calls to the msc wait/query functions
   can change the (ust,msc) results for WaitForSbc, e.g., if following
   scenario happens:

   1. Schedule bufferswap for some targetSBC.
   2. Swap completes -> PresentCompleteNotify Event -> Mesa stores msc,ust.
   3. Wait a refresh cycle or more, so msc,ust increment.
   4. glXGetSyncValues() query to server updates the msc,ust of
      swap completion from step 2 with msc, ust of last vblank.
   5. glXWaitForSBC for targetSBC returns immediately due to step 2
      which already happened multiple refresh cycles in the past. Returns
      the msc,ust of step 4. instead of from step 2, as old values have
      been overwritten!!

   Rereading the spec, one could interpret its wording in a way that this
   is actually compliant behaviour, so technically this wouldn't be a
   DRI3/Present bug in Mesa. However even if this should be correct behaviour
   on paper it would be completely non-sensical and fragile behaviour for any
   practical use of the spec. Needs discussion on xorg-devel/mesa-devel to see.
   Long-term might be better to replace our use of WaitForSBC with sole use of
   the swap events extension to avoid such pitfalls...
Screen/Linux: DRI3/Present (bug?) workaround II - Triple-buffering / n-buffering.

Mesa n-buffers its OpenGL backbuffers under DRI3/Present, with values
of n that can dynamically change depending on if bufferswaps currently
happen via CopySwaps or Pageflips, and if vsync is on or off, aka
swapinterval is non-zero or zero. These are performance optimizations
to achieve higher/more stable framerates for apps which want that.

The implementation is consistent with precise swap scheduling and
swap completion timestamping, aka triple-buffering done right :)

However, this means we can no longer make the assumption that
OpenGL bufferswaps performed via pageflipping actually retain
the contents of post-swap backbuffers as with pure double-buffering
and fixed buffers. Instead post-swap we may get a new uninitialized
backbuffer with undefined pixelcontent any time, depending on load
and other factors. This means that our video refresh calibration
and startup sync tests now need to draw the startup logo before every
bufferswap, otherwise users would see a lot of pixeltrash.

-> Add neccessary PsychDrawSplash() calls to calibration/testing
   loop.

-> So far so good. However the fact that omitting these calls not
   only causes pixeltrash at startup, but also totally weird tearing/
   unsynchronized rendering artifacts throughout a whole following
   work session - rendering corruption wherever you look - hints to
   some potential bug in Mesa 10.3.0's n-buffer management. One of
   these bugs nobody except us psycho-weirdo hits, because only we
   do strange things like sequences of bufferswaps without any
   rendering between bufferswaps. -> Needs investigation into the
   mechanism and root cause of this.

-> Screen for 64-Bit Octave on Linux rebuilt and tested.
Screen/Linux: DRI3/Present (bug?) workaround II - Triple-buffering / n-buffering.

Mesa n-buffers its OpenGL backbuffers under DRI3/Present, with values
of n that can dynamically change depending on if bufferswaps currently
happen via CopySwaps or Pageflips, and if vsync is on or off, aka
swapinterval is non-zero or zero. These are performance optimizations
to achieve higher/more stable framerates for apps which want that.

The implementation is consistent with precise swap scheduling and
swap completion timestamping, aka triple-buffering done right :)

See following Mesa commits for details:

Mesa 10.3:   3fbd1b0cb576b46ac8df2697cb388db78f48012d
Mesa master: f7a355556ef5fe23056299a77414f9ad8b5e5a1d

However, this means we can no longer make the assumption that
OpenGL bufferswaps performed via pageflipping actually retain
the contents of post-swap backbuffers as with pure double-buffering
and fixed buffers. Instead post-swap we may get a new uninitialized
backbuffer with undefined pixelcontent any time, depending on load
and other factors. This means that our video refresh calibration
and startup sync tests now need to draw the startup logo before every
bufferswap, otherwise users would see a lot of pixeltrash.

-> Add neccessary PsychDrawSplash() calls to calibration/testing
   loop.

-> So far so good. However the fact that omitting these calls not
   only causes pixeltrash at startup, but also totally weird tearing/
   unsynchronized rendering artifacts throughout a whole following
   work session - rendering corruption wherever you look - hints to
   some potential bug in Mesa 10.3.0's n-buffer management. One of
   these bugs nobody except us psycho-weirdo hits, because only we
   do strange things like sequences of bufferswaps without any
   rendering between bufferswaps. -> Needs investigation into the
   mechanism and root cause of this.

-> Screen for 64-Bit Octave on Linux rebuilt and tested.
Merge branch 'master' of https://github.com/kleinerm/Psychtoolbox-3
Screen for 64-Bit Octave on Linux rebuilt on 14.04-LTS.
Screen: Bits of whitespace/indentation cleanup in GStreamer videocapture.

Prepares next commit.
Screen: Make video setting validation for GStreamer-Videocapture less fragile.

This failed if the engine was able to enumerate capture caps, but
not actually parsed the entries. Auto-detection failed with bogus
values like an image size of 1 x 1 pixel. Manual override failed due
to validation failure.

Long story short, this makes sure that auto-detection falls back
to waiting for the first preroll buffer and online negotiation if
it can't enumerate modes it can actually parse. This way we get
at least some useful video mode. Validation of manually specified
settings now just accepts any given setting if it can't meaningfully
validate.

Makes the Delock 61769 USB-2.0 video grabber work better.
Work better means, we can get it to grab and return video
with proper timing and resolution. I don't know if the video
is actually valid video, as i didn't have an analog camera
to actually connect, so i could only see the all-blue standby
image. To be tested properly next week with an actual camera...

-> Screen for 64-Bit Octave on Linux rebuilt and tested.
Cleanup comments in LuminanceBlitShader.
Add new single-pass shader 'WeightedColorComponentSum'.

shader = CreateSinglePassImageProcessingShader(window, 'WeightedColorComponentSum');

creates a new shader for use with Screen('Drawtexture'). This one
takes the r,g,b,a color values of each texel, weights/multiplies
them by the 'modulateColor' color gain values as usual, but then
sums all of the four weighted values into a single scalar. Then
it replicates that scalar into all four RGBA output color compoments.

Iow., it computes the dotproduct of input texel and modulateColor
and assigns it to all RGBA output channels.

Some useful use cases:

- Turn luminance channel/luminance into an alpha mask by
  using modulateColor=[1,0,0,0] during drawing, so red values
  (which correspond to luminance in a luminance texture) get
  copied into alpha channel. Use Screen('Blendfunction') color
  write mask [0,0,0,1] to only the info into the alpha channel.

  More advanced: Use modulateColor [r,g,b,0] gains r,g,b to
  compute a real RGB->Gray luminance conversion.

  -> This is helpful if one wants to draw alpha-masks in the visual
     channel, so the resulting mask can be easily visualized for
     debugging. Also this allows (meta meta!) to use alpha blending
     and alpha channels to composite an alpha mask itself without
     warping ones brain.

- Abuse texture drawing for morphing up to 4 layers via a
  weighted sum of the four layers: modulatecolor = blend weight vector.